|
|
| (18 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| |
| − | = Release Cycle =
| |
| | | | |
| − | 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 find a link to the current development release schedule [[Releases|here]]. It is made of four major stages that will be described in this document.
| + | {{ caution|http://docs.openstack.org/project-team-guide/release-management.html|Update your links and bookmarks! You should read instead: }} |
| − | | |
| − | 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 strongly encouraged to align with the common 5-week milestone plan. This 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. 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 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|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 have a topic set that references one bug on Launchpad.
| |
| − | | |
| − | Every week during the QA stage, projects will produce a release candidate (RC). When a candidate is deemed ready, we import the trunk into the milestone-proposed branch, whose content will be released on the common release day. Trunk switches to the next development cycle, where new features can freely be merged. This point in time is called Release Branch Point, and it can differ for each project.
| |
| − | | |
| − | After that, only very rare, late release-critical bugs should be accepted in the milestone-proposed branch (and they should make it into trunk first). Significant bugs should get documented in the Release Notes instead.
| |
| − | | |
| − | This stage ends up individually for each project at Release Branch Point.
| |
| − | | |
| − | == 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.
| |
{{{header}}}
