Rev 5491: (vila) Tweak the release process based on ML discussion (Vincent Ladeuil) in file:///home/pqm/archives/thelove/bzr/%2Btrunk/
Canonical.com Patch Queue Manager
pqm at pqm.ubuntu.com
Wed Oct 13 08:04:51 BST 2010
At file:///home/pqm/archives/thelove/bzr/%2Btrunk/
------------------------------------------------------------
revno: 5491 [merge]
revision-id: pqm at pqm.ubuntu.com-20101013070450-xmn9cpnli5qnmrt8
parent: pqm at pqm.ubuntu.com-20101013043153-ki2mvt5miuxbun8l
parent: v.ladeuil+lp at free.fr-20101012155039-mkar8mft788azp7i
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Wed 2010-10-13 08:04:50 +0100
message:
(vila) Tweak the release process based on ML discussion (Vincent Ladeuil)
modified:
README README-20050309040720-8f368abf9f346b9d
doc/developers/cycle.txt cycle.txt-20081017031739-rw24r0cywm2ok3xu-1
doc/developers/ppa.txt ppa.txt-20080722055539-606u7t2z32t3ae4w-1
doc/developers/releasing.txt releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
doc/en/whats-new/whats-new-in-2.3.txt whatsnewin2.3.txt-20100818072501-x2h25r7jbnknvy30-1
=== modified file 'README'
--- a/README 2010-01-29 14:09:05 +0000
+++ b/README 2010-10-07 06:08:01 +0000
@@ -36,7 +36,7 @@
It also directly supports and encourages a large number of development best
practices like refactoring and pre-commit regression testing. Users can
choose between our command line tool and our cross-platform GUI application.
-For further details, see our website at http://bazaar-vcs.org/en.
+For further details, see our website at http://bazaar.canonical.com/en/
Feedback
========
=== 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-09-24 09:56:50 +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
@@ -25,6 +27,56 @@
bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
+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. 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::
+
+ #. 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
===============================
@@ -180,6 +232,9 @@
# API compatibility version: bzrlib is currently API compatible with 1.7.
+ Note that the NEWS file formatting has evolved, this example needs to
+ be updated.
+
#. Tag the new release::
bzr tag bzr-1.14
@@ -235,16 +290,18 @@
this changes what the download widget on the Launchpad bzr home
page shows, so don't stop the release process yet, or platform binary
installers won't be made and the download list will stay very small!
- <https://bugs.edge.launchpad.net/launchpad/+bug/586445>
+ <https://bugs.launchpad.net/launchpad/+bug/586445>
Announcing the source freeze
----------------------------
-#. Post to the ``bazaar`` list, saying that the source has been frozen.
- This is the cue for platform maintainers and plugin authors to update
- their code. This is done before the general public announcement of the
- release.
+#. Post to the ``bazaar`` list, saying that the source has been frozen
+ (gone gold). Be extra clear that this is only a *source* release
+ targeted at packagers and installer builders (see
+ <https://bugs.launchpad.net/launchpad/+bug/645084>). This is the cue
+ for platform maintainers and plugin authors to update their code. This
+ is done before the general public announcement of the release.
Kick off the next cycle
@@ -300,12 +357,12 @@
Subject: bzr x.y.z released!
- <<Summary paragraph from news>>
-
The Bazaar team is happy to announce availability of a new
release of the bzr adaptive version control system.
Bazaar is part of the GNU system <http://gnu.org/>.
+ <<Summary paragraph from news>>
+
Thanks to everyone who contributed patches, suggestions, and
feedback.
@@ -336,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-10-06 04:14:52 +0000
+++ b/doc/en/whats-new/whats-new-in-2.3.txt 2010-10-13 07:04:50 +0000
@@ -98,6 +98,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