Rev 4645: More tweaks. in file:///home/vila/src/bzr/bugs/releasing-clarified/

[Vincent Ladeuil]

At file:///home/vila/src/bzr/bugs/releasing-clarified/

------------------------------------------------------------
revno: 4645
revision-id: v.ladeuil+lp at free.fr-20090828150047-su0w9kdfv9z0hx0q
parent: v.ladeuil+lp at free.fr-20090828143526-mvgtlmu6qze975o0
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: releasing-clarified
timestamp: Fri 2009-08-28 17:00:47 +0200
message:
  More tweaks.
-------------- next part --------------
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	2009-08-28 14:35:26 +0000
+++ b/doc/developers/releasing.txt	2009-08-28 15:00:47 +0000
@@ -7,6 +7,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, I 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::
 
 
@@ -44,27 +51,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:
-
-#. Create a new milestone at <https://launchpad.net/bzr/2.0/+addmilestone>
-   for the beta release or release candidate.
-
-#. Make a beta release or release candidate.
-
-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.) ::
@@ -76,6 +70,7 @@
 
 	[/home/mbp/bzr/prepare-1.14]
 	pqm_email = Canonical PQM <pqm at bazaar-vcs.org>
+	parent_branch = lp:bzr/2.0
 	submit_branch = lp:bzr/2.0
 	public_branch = http://bazaar.example.com/prepare-2.0
 	submit_to = bazaar at lists.canonical.com
@@ -85,6 +80,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 +94,21 @@
        version_info = (2, 0, 1, 'candidate', 1)
 
 
+Starting the release phase
+--------------------------
+
+#. Create a new milestone at <https://launchpad.net/bzr/2.0/+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``::
 
@@ -285,10 +294,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.
+
 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 made it. Have a beer or a fruit juice, it's on the
+house and don't force you to drink alcohol.
+
+You have made your first release, that's great. If it was a beta, or
+candidate, you're not finished, 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 changed
+between beta, candidate and final releases, but they should be
+documented. If they aren't clear enough to your taste, fix them.
+
 
 See also
 --------