Jump to: navigation, search

Difference between revisions of "Release Cycle"

(Replaces old cycle model)
Line 23: Line 23:
 
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.
 
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.
  
A few days before the release of a milestone, we usually cut a milestone release branch for last-minute testing and fixing milestone-critical issues.
+
A few days before the release of a milestone, we usually cut a milestone release branch for last-minute testing and fixing milestone-critical issues. See [[BranchModel]] for more explanations on this.
  
 
== QA (The road to final release) ==
 
== QA (The road to final release) ==

Revision as of 14:47, 1 June 2011

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.

A few days before the release of a milestone, we usually cut a milestone release branch for last-minute testing and fixing milestone-critical issues. See BranchModel for more explanations on this.

QA (The road to final release)

The QA stage is when we turn most of our attention to testing the result of all the development effort and to fixing bugs. The last milestone in the Implementation stage is used to create the final release branch. Only branches that fix bugs and do not introduce new features are allowed to enter the release branch. Features can still land in Trunk, though. The resulting stability of the release candidate PPA 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.

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.