← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2009-11-23 23:42:16 UTC
  • mfrom: (4820.1.1 integration)
  • Revision ID: pqm@pqm.ubuntu.com-20091123234216-gwx0g4nd22xw247y
(vila) Further clarifications on building releases

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
8
8
This document gives a checklist you can follow from start to end in one
9
9
go.
10
10
 
 
11
If you're helping the Release Manager (RM) for one reason or another, you
 
12
may notice that he didn't follow that document scrupulously. He may have
 
13
good reasons to do that but he may also have missed some parts.
 
14
 
 
15
Follow the document yourself and don't hesitate to create the missing
 
16
milestones for example (we tend to forget these ones a lot).
 
17
 
11
18
.. contents::
12
19
 
13
20
 
45
52
   and their expected dates.
46
53
 
47
54
#. Update the version number in the ``bzr`` script, and the
48
 
   ``bzrlib/__init__.py`` file.
 
55
   ``bzrlib/__init__.py`` file. Make sure there is always a corresponding
 
56
   milestone when you change that version number.
49
57
 
50
58
#. Send mail to the list with the key dates, who will be the release
51
59
   manager, and the main themes or targeted bugs.  Ask people to nominate
52
60
   objectives, or point out any high-risk things that are best done early,
53
61
   or that interact with other changes. This is called the metronome mail
54
 
   and as RM you're supposed to send other metronome mails at your rythm.
55
 
 
56
 
 
57
 
Starting the release phase
58
 
--------------------------
59
 
 
60
 
When it's time to make the first beta release or release candidate:
61
 
 
62
 
#. Make a beta release or release candidate. The milestone for this
63
 
   candidate will already exist (see Starting a cycle above).
64
 
 
65
 
Preparing the tree for release
66
 
------------------------------
 
62
   and is described in `Development cycles <cycle.html>`_.
67
63
 
68
64
#. Make a local branch for preparing this release.  (Only for the first 
69
65
   release in a series, otherwise you should already have a branch.) ::
77
73
        [/home/mbp/bzr/prepare-x.y]
78
74
        pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
79
75
        submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
 
76
        parent_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
80
77
        public_branch = http://bazaar.example.com/prepare-x.y
81
78
        submit_to = bazaar@lists.canonical.com
82
79
        smtp_server = mail.example.com:25
85
82
    for more details on PQM
86
83
 
87
84
#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
 
85
   Make sure the corresponding milestone exists.
88
86
   Double check that ./bzr ``_script_version`` matches ``version_info``. Check
89
87
   the output of ``bzr --version``.
90
88
 
98
96
       version_info = (2, 0, 1, 'candidate', 1)
99
97
 
100
98
 
 
99
Starting the release phase
 
100
--------------------------
 
101
 
 
102
#. Create a new milestone at <https://launchpad.net/bzr/x.y/+addmilestone>
 
103
   for the beta release or release candidate if you haven't already.
 
104
 
101
105
#. Add the date and release number to ``./NEWS``
102
106
 
 
107
   What order to we keep here ? By major release or by date ? The bugfix
 
108
   release are likely to occur after the next major release has
 
109
   occurred. The workflow says that we should keep them sorted by release
 
110
   but that may be a bit disturbing for users reading the NEWS. Anyaw we
 
111
   should chose one and document it.
 
112
  
 
113
 
103
114
#. To check that all bugs mentioned in ``./NEWS`` are actually marked as
104
115
   closed in Launchpad, you can run ``tools/check-newsbugs.py``::
105
116
 
308
319
the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
309
320
back into pqm for bzr.dev.
310
321
 
 
322
As soon as you change the version number in trunk, make sure you have
 
323
created the corresponding milestone to ensure the continuity in bug
 
324
targeting or nominating. Depending on the change, you may even have to
 
325
create a new series (if your change the major or minor release number), in
 
326
that case go to `Starting a cycle` and follow the instructions from there.
 
327
 
311
328
You should also merge (not pull) the release branch into
312
329
``lp:~bzr/bzr/current``, so that branch contains the current released code
313
330
at any time.
314
331
 
 
332
Releases until the final one
 
333
----------------------------
 
334
 
 
335
Congratulations - you have made your first release.  Have a beer
 
336
or fruit juice - it's on the house! If it was a beta, or
 
337
candidate, you're not finished yet. Another beta or candidate or
 
338
hopefully a final release is still to come.
 
339
 
 
340
The process is the same as for the first release. Goto `Starting the
 
341
release phase`_ and follow the instructions again. Some details change
 
342
between beta, candidate and final releases, but they should be
 
343
documented. If the instructions aren't clear enough, please fix them.
 
344
 
315
345
 
316
346
See also
317
347
--------