Release Cycle

Starting with the Diablo release, the OpenStack release cycle abandoned its 3-month time-based cycle for a coordinated 6-month release cycle with frequent development milestones. 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.

Planning (Design, Discuss and Target)

The Planning stage is at the start of a cycle, 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. It usually lasts 3 weeks, with the Design Summit on the second week.

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

At the end of this stage the PTLs consider the submitted blueprints and accept a number of them in the cycle plan, with a Priority. The blueprints in the plan will be tracked by Release Management throughout the cycle and targeted to a specific milestone (to give the various stakeholders an idea on when the feature will land).

Implementation (Milestone iterations)

The Implementation stage is split into a number of milestone iterations. Core projects are free to choose their milestone plan, but without a good reason to differ, they are encouraged to align with the Nova 4-week milestone plan. That's where we actually write the code (or produce the documentation...) corresponding to those blueprints that were targeted at the end of the Planning stage. The work in progress should be published in a branch, which should be proposed for merging as soon as they are ready. In order to be reviewed in time for a milestone, the code should be proposed in the weeks before the milestone release date.

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.

Three days before the release of a milestone, we have the milestone branch point where we import the milestone development into a feature-frozen milestone-proposed branch (for last-minute testing and fixing milestone-critical issues). See BranchModel for more explanations on this.

QA (soft feature freeze, unrestricted bugfixes)

After the last milestone, we stop adding features and turn most of our attention to testing the result of all the development effort and to fixing bugs. Only branches that fix bugs and do not introduce new features should be allowed to enter trunk during this period. 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.
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.

This stage ends with the ReleaseBranchPoint.

RC (targeted bugfixes)

At ReleaseBranchPoint, we import the trunk into the milestone-proposed branch, from which release candidates are built. Trunk switches to the next development cycle, where new features can freely be merged.

After that, only release-critical bugs should be accepted in the milestone-proposed branch, and they should make it into trunk first. To track RC bugs, we use the final release milestone bug targets, which 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. The last candidate is used to make the release.

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.