Jump to: navigation, search

Release Cycle

Revision as of 02:56, 17 February 2013 by Ryan Lane (talk | contribs) (Ryan Lane moved page ReleaseCycle to 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. The Release Cycle is made of four major stages that will be described in this document.

Note: 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.

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, and create the corresponding blueprint that briefly describes how we want to do it. It usually lasts 4 weeks, with the Design Summit on the third week.

PTLs may use Launchpad blueprints to track the Planning stage, and in particular their "Design" field. See Blueprints 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 when we actually write the code (or produce the documentation...) corresponding to those blueprints that were targeted at the end of the Planning stage. 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 GerritWorkflow 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 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 create a milestone-proposed branch from the current state of the master branch. This branch is feature-frozen (only milestone-critical bugfixes are accepted) and is used for last-minute testing. See BranchModel for more details on this. Note that bugfixes are not allowed to land in the milestone-proposed branch unless they have been merged into the master branch first.

When we create the milestone-proposed branch for the last development milestone in a cycle, we apply two freezes: FeatureFreeze and StringFreeze, in order to stop accepting new features and disruptive changes and concentrate on stabilization.

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. 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.

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 milestone-proposed branch from the current state of the master branch. The milestone-proposed branch will 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 milestone-proposed 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 core 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.

Milestone-proposed branch - A set of code that is derived from the master branch and where only last-minute 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.