Rev 5449: More updates following list discussion. in file:///home/vila/src/bzr/releases/work/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Tue Oct 12 16:50:39 BST 2010
At file:///home/vila/src/bzr/releases/work/
------------------------------------------------------------
revno: 5449
revision-id: v.ladeuil+lp at free.fr-20101012155039-mkar8mft788azp7i
parent: v.ladeuil+lp at free.fr-20101007060801-wfdhizfhfmctl8qa
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: work
timestamp: Tue 2010-10-12 17:50:39 +0200
message:
More updates following list discussion.
-------------- next part --------------
=== modified file 'doc/developers/cycle.txt'
--- a/doc/developers/cycle.txt 2010-01-08 00:44:26 +0000
+++ b/doc/developers/cycle.txt 2010-10-12 15:50:39 +0000
@@ -2,7 +2,7 @@
Bazaar Release Cycles
*********************
-:status: Current policy, as of 2009-08.
+:status: Current policy, as of 2010-10.
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
@@ -10,7 +10,7 @@
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
+stable series. 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.
@@ -25,11 +25,11 @@
The Process
************
-Bazaar will make a major release every six months, which will be supported
-at least until the time of the next major release. During this support
-period, we'll make incremental releases which fix bugs, but which do not
-change network or disk formats or command syntax, and which do not require
-updates to plugins.
+Bazaar will make a major release every six months, which will be supported at
+least until the time of the next major release and generally 18 months after
+the first final release in a series. During this support period, we'll make
+incremental releases which fix bugs, but which do not change network or disk
+formats or command syntax, and which do not require updates to plugins.
We will also run a development series, which will become the next major
release. We'll make a beta release from this every four weeks. The
@@ -75,15 +75,6 @@
often if there are serious bugs, perhaps much less often if no new changes
have landed.
-We will then make a release candidate for the next major release, and at
-this point create a release branch for it. We will iterate release
-candidates at approximately weekly intervals until there are no bugs
-blocking the final major release.
-
-Compared to the current process this has approximately the same amount of
-release-related work, because the extra releases from the stable branch
-are "paid for" by not doing RCs for the development series.
-
We will synchronize our major releases with Ubuntu, so that they come out
in sufficient time for some testing and margin of error before Ubuntu's
upstream freeze.
@@ -118,32 +109,40 @@
-----------
Major releases (2.0.0 or 2.1.0)
+
The big ones, every six months, intended to ship in distributions and
to be used by stability-oriented users.
Release candidate (2.0.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. We should avoid the
- confusing phrasing "release candidate 2.0.0rc1 is released"; instead
- use "available."
+
+ 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. We should avoid the confusing phrasing
+ "release candidate 2.0.0rc1 is released"; instead use "available."
+ Starting with the 2.3 series we don't plan on making release candidates
+ anymore.
Bugfix releases (2.0.1)
+
Based on the previous major release or bugfix; contains only bugfixes
and perhaps documentation or translation corrections.
Stable series
+
A major release and its descendant bugfix releases.
Stable release
+
Either a major release or a bugfix release.
Beta release (3.0.0beta1)
+
Made from trunk every month, except for the month there's a major
release. Stable and suitable for users who want the latest code and
can live with some changes from month to month.
Development series
+
The development releases leading up to a stable release.
Bug Work
@@ -183,8 +182,8 @@
Plugins that want to cooperate with this should make a series and a branch
that matches each bzr stable series, and follow similar rules in making
releases from their stable branch. We'd expect that plugins will make a
-release between the last development release of a series and the major
-release candidate.
+release between the first beta release of a series and the final major
+release.
Within a stable series, anything that breaks any known plugin is
considered an API break and will be avoided. Before
@@ -274,11 +273,11 @@
Packaging
---------
-At present we have three upstream-maintained PPAs containing Ubuntu
-packages of Bazaar: ``~bzr-nightly-ppa``, ``~bzr-beta-ppa`` (rcs and
-releases) and ``~bzr`` (ie stable). We will keep these PPAs, and reorient
-beta to contain the monthly beta releases, and the stable PPA to contain
-stable releases, their release candidates, and bugfixes to those releases.
+At present we have three upstream-maintained PPAs containing Ubuntu packages
+of Bazaar: ``~bzr-nightly-ppa``, ``~bzr-beta-ppa`` (beta releases) and
+``~bzr`` (ie stable). We will keep these PPAs, and reorient beta to contain
+the monthly beta releases, and the stable PPA to contain stable releases and
+bugfixes to those releases.
Some platforms with relatively less active packagers may choose to ship
only the stable releases. This is probably better than having them only
=== modified file 'doc/developers/ppa.txt'
--- a/doc/developers/ppa.txt 2010-09-20 12:05:38 +0000
+++ b/doc/developers/ppa.txt 2010-10-12 15:50:39 +0000
@@ -68,6 +68,8 @@
* Hardy LTS
* Dapper LTS (supported but no longer updated for new releases)
+The ``rmadison bzr`` command will gives you an up-to-date summary
+of which bzr releases are current in each Ubuntu release.
Preconditions
-------------
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt 2010-10-07 06:08:01 +0000
+++ b/doc/developers/releasing.txt 2010-10-12 15:50:39 +0000
@@ -2,10 +2,12 @@
################
This document describes the processes for making and announcing a Bazaar
-release, and managing the release process. This is just one phase of the
-`overall development cycle <http://doc.bazaar.canonical.com/developers/cycle.html>`_,
-but it's the most complex part. This document gives a checklist you can
-follow from start to end in one go.
+release, and managing the release process. This is just one phase of
+the `overall development cycle
+<http://doc.bazaar.canonical.com/developers/cycle.html>`_, (go re-read
+this document to ensure it hasn't been updated) but it's the most
+complex part. This document gives a checklist you can follow from start
+to end in one go.
If you're helping the Release Manager (RM) for one reason or another, you
may notice that he didn't follow that document scrupulously. He may have
@@ -24,121 +26,55 @@
bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
-Release provisional planning
-============================
-
-We currently maintain four series. Concurrently releasing them all at the
-same time makes it harder to shorten the delay between the source
-availability and the package building longer than necessary (we delay the
-official announcement until most of our users can install the new release).
+
+When do we relase ?
+===================
+
+As of October 2010, we mantain four series. Concurrently releasing them
+all at the same time makes it harder to shorten the delay between the
+source availability and the package building longer than necessary (we
+delay the official announcement until most of our users can install the new
+release).
In order to continue to do time-based releases, we need to plan the
-releases by series to minimize the collisions.
+releases by series to minimize the collisions. In the end, it's the Release
+Manager call to decide whether he prefers to do all releases at once
+though, so the rules presented here are a conservative approach.
We want to respect the following rules::
- * the most recent series should release once a month,
-
- * the most recent stable series should release every other month (based
- on the amount of bug fixes, this can be shorter or longer depending
- on the bugs importance),
-
- * previous series should relesase on a a regular basis without
- interfering with the most recent series with a decreasing order of
- priority (again this should be based on bugs importance and user
- feedback,
-
- * the death of a series should be planned ahead of time. 6 months
- should give enough time to our users to migrate to a more recent
- series,
-
- * there should not be more than 2 releases in the same week (but the
- Release Manager is free to ignore this (get in touch with packagers
- though),
-
- * the series are aligned with Ubuntu releases for convenience since we
- create a new series every 6 months. This means that we support the
- stable series for 2 years. Note that we also propose the most recent
- stable series via the ppa, so whether we keep supporting LTS directly
- or via the ppa is still an open question.
-
-
-2.3 series
-----------
-
-The 2.3 series has entered the beta phase and 2.3.0 should be released soon
-enough to be included into Natty Narwhal. This gives the following expected
-releases::
-
- * 2.3.0: 2011-02-03
-
- * 2.3rc2: 2011-01-06
-
- * 2.3rc1: 2010-12-02
-
- * 2.3b3: 2010-11-04
-
- * 2.3b2: 2010-10-08
-
- * 2.3.b1: 2010-09-19
-
-2.2 series
-----------
-
-The 2.2 series is the current stable release and is included in Maverick
-Meerkat. The planned releases are::
-
- * 2.2.3: 2010-12-16
-
- * 2.2.2: 2010-11-18
-
- * 2.2.1: 2010-09-17
-
- * 2.2.0: 2010-08-06
-
-
-2.1 series
-----------
-
-The 2.1 series is the stable release included in Lucid Lynx. The planned
-releases are::
-
- * 2.1.6: 2011-01
-
- * 2.1.5: 2010-12
-
- * 2.1.4: 2010-11
-
- * 2.1.3: 2010-09-16
-
- * 2.1.2: 2010-05-27
-
- * 2.1.1: 2010-03-02
-
- * 2.1.0: 2010-02-11
-
-
-2.0 series
-----------
-
-The 2.0 series is the stable release included in Karmic Koala. The planned
-release are::
-
- * 2.0.7: 2011-03 will be the last release for the 2.0 series.
-
- * 2.0.6: 2010-09-16
-
- * 2.0.5: 2010-03-22
-
- * 2.0.4: 2010-01-21
-
- * 2.0.3: 2009-12-14
-
- * 2.0.2: 2009-11-02
-
- * 2.0.1: 2009-10-14
-
- * 2.0.0: 2009-09-21
+ #. as much as possible releases should not disturb development, and
+ ongoing development should not disturb releases,
+
+ #. the most recent development series should release once a month during
+ the beta period (see `Development cycles <cycle.html>`_ for more
+ details),
+
+ #. the most recent stable series should release every other month (based
+ on the amount of bug fixes, this can be shorter or longer depending on
+ the bugs importance),
+
+ #. previous series should relesase on a regular basis without interfering
+ with the most recent series with a decreasing order of priority (again
+ this should be based on bugs importance and user feedback),
+
+ #. the death of a series should be planned ahead of time. 6 months should
+ give enough time to our users to migrate to a more recent series. This
+ doesn't mean we will make a release at the end of the series, just that
+ before the end date we _could_ possibly put out another release if
+ there was a sufficiently important fix. Beyond that date, we won't
+ even land changes on that branch (unless something causes a miraculous
+ resurrection.)
+
+ #. there should not be more than 2 releases in the same week (but the
+ Release Manager is free to ignore this (get in touch with packagers
+ though),
+
+ #. the series are aligned with Ubuntu releases for convenience since we
+ create a new series every 6 months. This means that we support the
+ stable series for 18 months. Note that we also propose the most recent
+ stable series via the ppa, so whether we keep supporting LTS directly
+ or via the ppa is still an open question.
At the start of a release cycle
@@ -457,7 +393,8 @@
python setup.py register
- Remember to check the results afterwards.
+ Remember to check the results afterwards -- this should be done for
+ final releases but not for beta releases or Release Candidates.
To be able to register the release you must create an account on
<http://pypi.python.org/pypi> and have one of the existing owners of
=== modified file 'doc/en/whats-new/whats-new-in-2.3.txt'
--- a/doc/en/whats-new/whats-new-in-2.3.txt 2010-09-24 02:19:28 +0000
+++ b/doc/en/whats-new/whats-new-in-2.3.txt 2010-10-12 15:50:39 +0000
@@ -92,6 +92,17 @@
(Vincent Ladeuil, #219334)
+Expected releases for the 2.3 series
+************************************
+
+The 2.3 series has entered the beta phase and 2.3.0 should be released soon
+enough to be included into Natty Narwhal.
+
+As a rough estimate, consider that 2.3.0 will be released in February
+2011 and be supported until August 2012. Additional releases will be
+made if critical bugs are encountered
+
+
Further information
*******************
More information about the bazaar-commits
mailing list