View source for Yocto Project v. 1.0 Release Cycle

= Yocto Project v1.0 Release Plan = 

== Introduction ==

This release plan addresses the upcoming Yocto Project 1.0 release. This document will address some basic release methodologies and scheduling of sprint M4. It does not address planned features or the overall project schedule. 

=== Notes ===
All dates and times are based upon US-Pacific Time. Future release plans should use UTC time to avoid any potential confusion.

== Release Cycle Overview ==
The release cycle is scheduled to begin Feb 7<sup>th</sup> 2011 and officially ends April 15<sup>th</sup> 2011. During that period, we've planned for three potential release windows. Our projected release date is April 1<sup>st</sup> 2011. Two more contingency release windows are planned, one on April 8<sup>th</sup> and another on April 15<sup>th</sup>. 

The release cycle is split into 3 periods; master stabilization, release candidate verification/validation and the release window.

=== Master Stabilization Cycle ===
The master stabilzation period begins Feb 7th allows developers 20 days between the beginning of the release cycle to the day we generate the release candidate to ensure that master is stable. Because Yocto has a very long build cycle and an active developer community, we need to ensure that adequate time is spent ensuring that Master is stable. 

==== Entry Criteria: ====
* Feature Complete as determined by the Release Readiness Review

==== Exit Criteria: ==== 
* A complete error free build of milestone on autobuilder.pokylinux.org
* List of known bugs and severity that meet standard metrics.

==== Deliverables: ====
* A release candidate branch
* A release candidate generated from the release candidate branch<br/> 

==== Feature Freeze ====
Feature freeze occurs on the first day of the release cycle. It is extraordinarily important that no new features are added to master during the period of feature freeze and the generation of the release candidate (20 days later). We do not generate an RC branch at feature freeze in order to minimize the amount of time spent maintaining two code branches and to maximize our QA effort. If a feature is submitted during this period, unless it is absolutely vital, the pull to master should be staged in disro/testing and pulled after the generation of the release candidate.

==== Bug Day ====
As an open source project, we should adopt an open bug day similar to that of the Mozilla project. This should occur regularly throughout the project, but is particularly vital during the release period. Bug Days should occur on #yocto and consist of defect “scrubbing”.

==== Release Branch Generation ====
At the end of the Master Stabilization Cycle, master is tagged and branched as the 1.0 RC (naming conventions. If we don't have them yet, I'll be making them up soon) and all developers, QA and build and release, who need to fix bugs for the upcoming release should switch to the release candidate branch of master. Once the release branch is generated, all pulls that have been staged to distro/testing should occur and master is now considered unfrozen.

[[File:Master.jpg |thumb |''Master Release Cycle Overview'']]

=== Release Candidate Verification/Validation Cycle ===
This cycle exists to uncover deeper bugs, expose documentation errors and allow us time to generate a quality release and begin the Release Cycle.

==== Exit Criteria: ==== 
* A complete error free final build of milestone on autobuilder.pokylinux.org
* Final build generated.
* Code freeze on RC branch
* 100% bug fixes merged from RC to master
* List of known bugs and severity that meet standard metrics.
* Documentation testing complete.

==== Deliverables: ====
* A final release ready to be pushed to mirrors
* A list of known open defects
* Mirrors alerted to pending release
* All documentation (manual, quickstart guide, release notes) is generated and any defects in documentation noted.

==== Code Freeze ==== 
Code Freeze means exactly that. Prior to the preliminary release readiness review, a code freeze will be in place for one week to allow one full QA weekly test cycle. Should we decide that we are ready to enter the final release cycle, that code freeze becomes final and all developers should switch back to master. Should the release readiness review process decide we are unable to release at the expected date, the RC branch is defrosted and we adjust our schedules to the next available release window.

==== Final Release Generation ==== 
At the end of the Release Candidate Cycle, the release candidate branch is tagged as (whatever the naming convention is for a major/minor release). 

[[File:RCP.jpg | thumb |   ''Release Candidate Cycle Overview'']]

=== Release Window ===

==== Exit Criteria: ====  
* A complete error free final build of the yocto v1.0 tag on autobuilder.pokylinux.org
* Final build pushed to mirrors.
* Mirror announcement made with final build metrics.
* Complete release notes
* Announcement generated and sent
* List of known bugs and severity that meet standard metrics.
* Documentation delivered and pushed to mirrors.

==== Deliverable: ==== 
* A feature complete, error free, release of Yocto v1.0.

==== Final QA Cycle ==== 
The test plan for Yocto is documented elsewhere. In addition to this test plan, some “non-yocto” testers should be recruited from the community to verify the Quickstart guide as well as the documentation. 

==== Mirrors ==== 
One week into the release cycle, the Gold build of Yocto v1.0 should be rsynced to the mirrors non-world accessable. This will allow time for mirror propagation. Once documentation is considered complete, this should be added to the rsync directory (NOT the tarball). Once the final Release Readiness Review is complete and the release is given the green light, the world readable bit should be set on the rsync directory and files, the announcement sent out and the release should be considered complete.

[[Image:Release.jpg|thumb| ''Release Window'']]

=== Date Slip ===
Once we enter the final release period, we should have a very high degree of certainty that no fatal defects exist. Should the QA process uncover an unacceptable fatal defect that will cause our release to slip, we have two contingency release dates spaced a week apart. While a slipped date is unfortunate (but avoidable!) we allow for this possibility. 

Should the release date slip, the mirror maintainers should be notified that our date will slip. The mirror maintainers require one week for release propagation, which gives us two possible release windows.

The following schedules show the latest date a slip date can occur in order for Yocto v 1.0 to ship. The decision, therefore to enter one of the slip date release windows should come out of one of the release readiness reviews. For the first slipped date release window, the release readiness review committee would have to identify a miss by the release readiness review at the very latest on March 25<sup>th</sup>. This would allow for 3 weeks. Should we get to the release readiness review on March 31<sup>st</sup> and come to the conclusion that we cannot ship on the first slipped releases date, April 4<sup>th</sup> 2011, we enter into the second slipped date release window.

As this is a theoretical scenario, we should be prepared to do some small amount of playing it by ear when it comes to slipped dates. The obvious places where we're going to identify a slipped date is at the release readiness reviews, which is why there are more of them during this release process than the last.

[[Image:Slipped.jpg|thumb|''Slipped Date Release Windows 1'']]

[[Image:Slipped.jpg|thumb|''Slipped Date Release Windows 2'']]