Rev 4821: (vila) Further clarifications on building releases in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

[Canonical.com Patch Queue Manager]

At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 4821 [merge]
revision-id: pqm at pqm.ubuntu.com-20091123234216-gwx0g4nd22xw247y
parent: pqm at pqm.ubuntu.com-20091123014435-71sjh9f83ull0oqj
parent: v.ladeuil+lp at free.fr-20091123225443-vcyt1n0pxml4qz6u
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Mon 2009-11-23 23:42:16 +0000
message:
  (vila) Further clarifications on building releases
modified:
  doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	2009-10-15 04:01:26 +0000
+++ b/doc/developers/releasing.txt	2009-11-23 22:54:43 +0000
@@ -8,6 +8,13 @@
 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
+good reasons to do that but he may also have missed some parts.
+
+Follow the document yourself and don't hesitate to create the missing
+milestones for example (we tend to forget these ones a lot).
+
 .. contents::
 
 
@@ -45,25 +52,14 @@
    and their expected dates.
 
 #. Update the version number in the ``bzr`` script, and the
-   ``bzrlib/__init__.py`` file.
+   ``bzrlib/__init__.py`` file. Make sure there is always a corresponding
+   milestone when you change that version number.
 
 #. Send mail to the list with the key dates, who will be the release
    manager, and the main themes or targeted bugs.  Ask people to nominate
    objectives, or point out any high-risk things that are best done early,
    or that interact with other changes. This is called the metronome mail
-   and as RM you're supposed to send other metronome mails at your rythm.
-
-
-Starting the release phase
---------------------------
-
-When it's time to make the first beta release or release candidate:
-
-#. Make a beta release or release candidate. The milestone for this
-   candidate will already exist (see Starting a cycle above).
-
-Preparing the tree for release
-------------------------------
+   and is described in `Development cycles <cycle.html>`_.
 
 #. Make a local branch for preparing this release.  (Only for the first 
    release in a series, otherwise you should already have a branch.) ::
@@ -77,6 +73,7 @@
 	[/home/mbp/bzr/prepare-x.y]
 	pqm_email = Canonical PQM <pqm at bazaar-vcs.org>
 	submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
+	parent_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
 	public_branch = http://bazaar.example.com/prepare-x.y
 	submit_to = bazaar at lists.canonical.com
 	smtp_server = mail.example.com:25
@@ -85,6 +82,7 @@
     for more details on PQM
 
 #. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
+   Make sure the corresponding milestone exists.
    Double check that ./bzr ``_script_version`` matches ``version_info``. Check
    the output of ``bzr --version``.
 
@@ -98,8 +96,21 @@
        version_info = (2, 0, 1, 'candidate', 1)
 
 
+Starting the release phase
+--------------------------
+
+#. Create a new milestone at <https://launchpad.net/bzr/x.y/+addmilestone>
+   for the beta release or release candidate if you haven't already.
+
 #. Add the date and release number to ``./NEWS``
 
+   What order to we keep here ? By major release or by date ? The bugfix
+   release are likely to occur after the next major release has
+   occurred. The workflow says that we should keep them sorted by release
+   but that may be a bit disturbing for users reading the NEWS. Anyaw we
+   should chose one and document it.
+  
+
 #. To check that all bugs mentioned in ``./NEWS`` are actually marked as
    closed in Launchpad, you can run ``tools/check-newsbugs.py``::
 
@@ -308,10 +319,29 @@
 the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
 back into pqm for bzr.dev.
 
+As soon as you change the version number in trunk, make sure you have
+created the corresponding milestone to ensure the continuity in bug
+targeting or nominating. Depending on the change, you may even have to
+create a new series (if your change the major or minor release number), in
+that case go to `Starting a cycle` and follow the instructions from there.
+
 You should also merge (not pull) the release branch into
 ``lp:~bzr/bzr/current``, so that branch contains the current released code
 at any time.
 
+Releases until the final one
+----------------------------
+
+Congratulations - you have made your first release.  Have a beer
+or fruit juice - it's on the house! If it was a beta, or
+candidate, you're not finished yet. Another beta or candidate or
+hopefully a final release is still to come.
+
+The process is the same as for the first release. Goto `Starting the
+release phase`_ and follow the instructions again. Some details change
+between beta, candidate and final releases, but they should be
+documented. If the instructions aren't clear enough, please fix them.
+
 
 See also
 --------