Jump to: navigation, search

Difference between revisions of "Release Cycle"

(Replaced content with " {{ caution|http://docs.openstack.org/project-team-guide/release-management.html|Update your links and bookmarks! You should read instead: }}")
Line 1: Line 1:
{{ caution|http://docs.openstack.org/project-team-guide/release-management.html|This page is deprecated. You should read instead: }}
{{ caution|http://docs.openstack.org/project-team-guide/release-management.html|Update your links and bookmarks! You should read instead: }}
Starting with the Diablo release, the OpenStack release cycle abandoned its [[3MonthReleaseCycle|3-month time-based cycle]] for a coordinated 6-month release cycle with frequent development milestones. You can see the current development release schedule [[Current_release_schedule|here]]. The Release Cycle is made of four major stages that will be described in this document.
Note: Nothing prevents you from doing a particular task outside of the designated stages. You can design during the QA stage. You can write new code on release week. The release cycle just gives you a general idea of what's the general team focus, it is not meant to restrict you in any way.
Note: Each core project is free to choose a different release cycle contents, as long as they submit a version for the common OpenStack release at the end of the cycle. However, unless they have a good reason to differ, they are strongly encouraged to follow the common plan that is described in this document.
== Planning (Design, Discuss and Target) ==
The Planning stage is at the start of a cycle, just after the previous release, when we take a step back and focus on what we want to do for the next one. We discuss it with our peers to get their feedback and comments, in most cases proposing a spec document that precisely describes how we want to do it. It usually lasts 4 weeks, with the Design [[Summit]] on the third week.
Contributors may propose new specs at any moment in the cycle, not just during the Planning stage. However doing so during the planning stage is preferred, so that contributors can benefit from Design Summit discussion and PTLs can include those features into their cycle roadmap.
Once the spec is approved by the corresponding project drivers, implementation is tracked in a blueprint, where a priority is set and a target milestone is defined, communicating when in the cycle the feature is likely to land. See [[Blueprints]] for details.
== Implementation (Milestone iterations) ==
The Implementation stage is when we actually write the code (or produce the documentation...) corresponding to those blueprints. It is split into a number of milestone iterations.
Once your work is deemed ready to be proposed for merging into the master branch, it should be pushed to our Gerrit review system for public review. See [http://docs.openstack.org/infra/manual/developers.html#development-workflow development workflow] for details. Note that in order to be fully reviewed in time for a milestone, the change should be proposed in the weeks '''before''' the milestone publication date.
We use Launchpad blueprints to track the Implementation stage, and in particular their "Implementation" field. See [[Blueprints]] for details.
Note that all "features" don't have to go through the blueprints tracking: feel free to submit any change as you see fit! We use specs & blueprints to discuss the design and track the progress of the major features in a release, not to prevent you from getting nice code and fixes into OpenStack.
Development milestones are tagged directly on the master branch during a two-day window (typically between the Tuesday and the Thursday of a milestone week).
At the last development milestone we apply three freezes: [[FeatureFreeze]], [[DepFreeze]] and [[StringFreeze]], in order to stop accepting new features and disruptive changes and concentrate on stabilization, packaging and translation.
== Pre-release (Release Candidates dance) ==
After the last milestone and until the final release, we turn most of our attention to testing the result of all the development effort and to fixing release-critical bugs. So:
* Kick the tires on it like never before, and file bugs about everything you find, be it small bugs, big bugs, misfeatures, or missing features. Anything. It's better to have problems be known and understood than ignored.
* Help prioritize bugs (see [[BugTriage]]).
* Help write [[Documentation|documentation]]. Our software can be as cool as it wants, but if our docs aren't any good, people won't be able to use it anyway.
* Last, but certainly not least, fix as many bugs as you can.
* See [[Bugs]] for a more detailed view.
'''Please see [[BranchModel]] for a clearer explanation of the various tags and branches.'''
=== Release candidate 1 ===
Between the last milestone and the RC1 publication, we stop adding features and concentrate on bugfixes. Only changes that fix bugs and do not introduce new features should be allowed to enter the master branch during this period. Any change proposed for the master branch should at least reference one bug on Launchpad.
Once all the release-critical bugs are fixed, we produce the first release candidate for that project (RC1). This RC1 built will be used as-is as the final release, unless new release-critical issues are found that warrant a RC respin.
We create a stable/* branch from the current state of the master branch (for example, ''stable/kilo'' for the Juno series). During the pre-release period, the stable/* branch will use a specific ACL (to be controlled by the release team) and be used to fix any new release-critical issue that is discovered until the common release day. The master branch switches to the next development cycle, and new features can freely be merged again.
=== Other release candidates ===
During the time between RC1 and final release, we look for regressions and integration issues that were missed before. If new release-critical bugs are found in the RC1, a decision can be made to respin the RC. A new milestone will be open (RC2), with bugs targeted to it. Those RC bugfixes need to be merged in the master branch before they are allowed to land in the stable/* branch. Once all those new release-critical bugs are fixed, the new RC is published.
This process is repeated as many times as necessary before the final release. As we get closer to the final release date, to avoid introducing last-minute regressions, we limit the number of changes and their impact: only extremely-critical and non-invasive bugfixes can get merged. All the other bugs are documented as known issues in the Release Notes instead.
=== Release day ===
On release day, the last published Release Candidate of each integrated project is collected and the result is published collectively as the OpenStack release for this cycle.
== Glossary ==
Blueprints - Lightweight specifications registered on the Launchpad site, used for tracking new features added to OpenStack core projects. See [[Blueprints]].
Bug - A software defect reported through Launchpad in the Bugs section by anyone with a Launchpad account. See [[Bugs]].
Launchpad - A collaborative open source project management tool available at http://launchpad.net.
master branch - The working set of code that is the project's development focus and the most recent and fresh set of code. See [[BranchModel]].
Pre-release stable/* branch - A set of code that is derived from the master branch and where only release-critical bugfixes are accepted. See [[BranchModel]].
PTLs - Project Technical Leads. A PTL is the elected technical leader of a given OpenStack core project. See [[Governance]].
Release Candidate - Project deliverable containing the source code for a given core project, potentially releasable as part of the OpenStack final release.

Latest revision as of 15:36, 13 June 2016

Caution icon.svg {{{header}}}