Obsolete:3MonthReleaseCycle

3-month Release Cycle

/!\ This is deprecated and kept for history reasons Please check ReleaseCycle instead.

The OpenStack release cycle is a 3-month time-based cycle that creates a cadence and focuses the OpenStack development efforts. You can find a link to the current development release schedule here. It is made of four major stages that will be described in this document.

Note that nothing prevents you to do 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.

Design

The Design stage is when we take a step back and focus on what we want to do, discuss it with our peers to get their feedback and comments, and write the corresponding specs document that briefly outline how we want to do it. Every two cycles we have a longer design phase in order to hold a Design Summit.

We use Launchpad blueprints to track the Design stage, and in particular their "Design" field. See BlueprintsLifecycle for details.

This stage ends up with SpecsSubmissionDeadline.

Implementation

The Implementation stage is when we actually write the code (or produce the documentation...) corresponding to those blueprints that were accepted at the end of the Design stage. The work in progress should be published in a branch, which should be proposed for merging as soon as they are ready, and in all cases before BranchMergeProposalFreeze.

We also use Launchpad blueprints to track the Implementation stage, and in particular their "Implementation" field. See BlueprintsLifecycle for details.

Note that all "features" don't have to go through the blueprints tracking: feel free to submit any branch that you see fit! We use blueprints to discuss the design and track the progress of the major features in a release, not to prevent you from getting nice code into OpenStack.

This stage ends up with FeatureFreeze.

QA

The QA stage is when we turn most of our attention to testing the result of all the merging effort and to fixing bugs. The general rule is: Only branches that fix bugs and do not introduce new features are allowed to enter trunk. Of course, bugs can be fixed at any time during the cycle, but the closer we get to release, less code gets merged: the stability of the resulting software makes it easier to test it. 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 prioritise bugs. We haven't yet come up with good definitions of what constitutes a critical, high, etc. bug, so just use your best judgment for now. We only have a couple of weeks before release, so we need to make sure we spend our time wisely.
• Help write 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 BugsLifecycle for a more detailed view.

Any branch proposed for merging into trunk should reference one or more bugs on Launchpad. You do this by passing something like --fixes lp:656744 to bzr commit. This stores the bug reference in the bzr metadata, and it turns up neatly in merge proposals and on the branch pages on Launchpad. If you forgot to do this when committing, you can manually link a branch to a bug on Launchpad.

We use a release-critical buglist to track the QA stage. That list contains high-priority bugs that we really want to fix before release.

The closer we get to release, the less changes we accept. The idea is to weigh all bugfixes against a perceived benefit / risk of regression trade-off : a known bug is sometimes better than an unknown regression. In the first part of this stage (up to GammaFreeze), any bug fix is accepted. After GammaFreeze, we try to limit bugfixes to the release-critical buglist.

This stage ends up with RCFreeze.

Release

The last few days of the release cycle are the actual release of the code. After RCFreeze, only exceptional circumstances would allow to merge new bug fixes.

This stage ends up with the Release day.

Glossary

Blueprints - Lightweight specifications created with a web form on the Launchpad site.

Bug - A software defect reported through Launchpad in the Bugs section by anyone with a Launchpad account.

Launchpad - A collaborative code tracking tool available at http://launchpad.net.

Trunk - The working set of code that is the project's development focus and the most recent and fresh set of code.