[rfc] six-month stable release cycles
Martin Pool
mbp at canonical.com
Wed Aug 12 11:49:18 BST 2009
Here's the diff I've made to this document to integrate the list
thread. I'll soon propose it for merging into the developer docs.
At this point I consider this settled: we've had a good discussion,
picked up some important improvements on the original plan, and it
looks good. Now let's do it and see how it works out in practice.
--
Martin <http://launchpad.net/~mbp/>
=== modified file 'release-cycles.txt'
--- release-cycles.txt 2009-07-29 06:33:13 +0000
+++ release-cycles.txt 2009-08-12 05:42:41 +0000
@@ -1,10 +1,20 @@
-***********************
-Bazaar Six-Month Cycles
-***********************
+*********************
+Bazaar Release Cycles
+*********************
-:status: Draft proposal, as of 2009-07
+:status: Current policy, as of 2009-08.
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
+
+Our users want easy access to bug fixes without other changes to the
+core product. They also want a Just Works experience across the full
+Bazaar ecosystem. To deliver the first and enable the second, we're
+adopting some standard process patterns: a 6 monthly release cycle and a
+stable branch. These changes will also have other benefits, including
+better availability of bug fixes in OS distributions, more freedom to
+remove old code, and less work for in packaging.
+
+
The Problem Situation
*********************
@@ -42,7 +52,14 @@
* Any effort we, or distributors, wanted to put into backporting fixes
would be dissipated across many possible backport target releases.
-The Proposal
+* When in the past we've tried either stalling releases for particular
+ features, or having trunk frozen for some weeks, it causes churn and
+ waste. People rush features in, or already landed features wait a long
+ time to be released, or branches go out of date because they cannot
+ land.
+
+
+The Process
************
Bazaar will make a major release every six months, which will be supported
@@ -63,6 +80,11 @@
continue: any beta release could potentially be supported in the long
term, but we identify particular releases that actually will be supported.
+The trunk will never be frozen: changes that pass review, other quality
+checks and that are agreed amongst the developers can always be landed
+into trunk. The only restrictions will be on branches specifically
+targeted at a release.
+
Schedule
--------
@@ -71,10 +93,10 @@
2.0 --- 2.0.1 -- 2.0.2 -- ...
\
- +--3.0beta1 -- 3.0beta2 -- ... -- 3.0rc1 -- 3.0 -- 3.0.1 -- ...
+ +--2.1beta1 -- 2.1beta2 -- ... -- 2.1rc1 -- 2.1 -- 2.1.1 -- ...
\
\
- +-- 4.0beta1 ...
+ +-- 3.0beta1 ...
Starting from the date of a major release:
@@ -104,17 +126,30 @@
upstream freeze.
-Names and Numbers
------------------
-
-Major releases (2.0)
+Numbering
+---------
+
+The number for a six-month cycle is chosen at the start, with an increment
+to either the first field (3.0) or second field (3.1) depending on what we
+expect to be the user impact of the release. We expect releases that
+culminate in a new disk format or that require changes in how people use
+the tool will get a new major number. We can change (forward only) if it
+turns out that we land larger changes than were expected.
+
+
+Terminology
+-----------
+
+Major releases (2.0 or 2.1)
The big ones, every six months, intended to ship in distributions and
to be used by stability-oriented users.
Release candidate (2.0rc1)
A preview of a major release, made one or a few weeks beforehand at
the time the release branch is created. There should be few if any
- changes from the rc to the stable release.
+ changes from the rc to the stable release. We should avoid the
+ confusing phrasing "release candidate 2.0rc1 is released"; instead use
+ "available."
Bugfix releases (2.0.1)
Based on the previous major release or bugfix; contains only bugfixes
@@ -134,7 +169,6 @@
Development series
The development releases leading up to a stable release.
-
Bug Work
--------
@@ -210,19 +244,15 @@
able to interoperate with all previous releases as at present.
Each major release will have one recommended data format which will be the
-default. This is not to say that every major release will change it;
-they should change less often.
-
-During a development series we may have a series of experimental formats;
-towards the end of the development series we will mark one as stable and
-target it to become the default for the upcoming major release.
-
-There is no promise of compatibility between development releases. In
-general we will not break compatibility but it leaves the option open that
-if something inserted in one development release turns out to be bad it
-can just be removed in the next. We will of course not leave users of
-beta versions stranded: there will always be a way for them to move their
-data forward.
+default. The name of the format will indicate which release series (not
+specific release) it comes from: '2a' is the first supported format for
+the 2.0 series.
+
+During a development series we may have a series of experimental formats.
+We will not leave people stranded if they test these formats, but we also
+won't guarantee to keep supporting them in a future release. If something
+inserted in one development release turns out to be bad it can just be
+removed in the next.
Hosting Services
@@ -275,6 +305,19 @@
only the stable releases. This is probably better than having them only
intermittently or slowly ship the monthly releases.
+Binary installers should use a version number like '2.0-1' or '2.0beta1-1'
+so that the last component just reflects the packaging version, and can be
+incremented if a new installer is made with no upstream source changes.
+
+
+Code Freeze vs Announcement
+---------------------------
+
+We will separate the code freeze for a particular release from its actual
+announcement, allowing a window of approximately one week for plugins to
+be released and binary installers to be built. On the date the
+announcement is published, people will be able to easily install it.
+
Questions
*********
@@ -301,3 +344,42 @@
Will anyone test the beta releases?
Probably yes, our most active users will run them, but if people would
really rather not test them, forcing them is not helpful.
+
+Isn't this a step backwards to a slower, less-agile process?
+ No, our trunk stays releasable, and we ship every month. We're just
+ cutting out things that hold us back (continuous rather than episodic
+ API stability; RCs every month) and giving users what they demand.
+
+How about calling the monthly releases "milestone" or "next" not "beta"?
+ Those words are less scary but they also have less clear meanings.
+
+
+Expected Benefits
+*****************
+
+If this plan works, we'll expect to see the following changes. If they
+don't occur, we'll think again:
+
+* We see a distribution curve of users and bug reports across nightly, monthly
+ and stable releases, indicating that each has value.
+
+* API changes are easier or safer to make during beta periods, without
+ being held back by fears of compatibility or
+
+* The stable releases are actually stable and don't introduce regressions
+ or break plugins.
+
+* Many bugs are fixed in stable branches, without developers feeling this
+ is a waste of time.
+
+* Distributions ship the stable releases in their stable releases and the
+ bugfix releases in their bugfix releases.
+
+* Plugin authors follow this policy, making their own bugfix releases.
+
+* Users like it.
+
+References
+**********
+
+#. List thread "[rfc] six-month stable release cycles", July 2009.
More information about the bazaar
mailing list