← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: John Arbash Meinel
  • Date: 2010-02-17 17:11:16 UTC
  • mfrom: (4797.2.17 2.1)
  • mto: (4797.2.18 2.1)
  • mto: This revision was merged to the branch mainline in revision 5055.
  • Revision ID: john@arbash-meinel.com-20100217171116-h7t9223ystbnx5h8
merge bzr.2.1 in preparation for NEWS entry.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
2
2
================
3
3
 
4
4
This document describes the processes for making and announcing a Bazaar
5
 
release, and managing the release process.  This is just one phase of the 
 
5
release, and managing the release process.  This is just one phase of the
6
6
`overall development cycle <http://doc.bazaar-vcs.org/developers/cycle.html>`_,
7
7
but it's the most complex part.
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
 
35
42
   will be available for targeting or nominating bugs.
36
43
 
37
44
#. We create a new pqm-controlled branch for this release series, by
38
 
   asking a Canonical sysadmin.  
 
45
   asking a Canonical sysadmin.
39
46
   This branch means that from the first release beta or candidate onwards,
40
47
   general development continues on the trunk, and only
41
48
   specifically-targeted fixes go into the release branch.
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
 
------------------------------
67
 
 
68
 
#. Make a local branch for preparing this release.  (Only for the first 
 
62
   and is described in `Development cycles <cycle.html>`_.
 
63
 
 
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.) ::
70
66
 
71
67
     bzr branch trunk prepare-1.14
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
   Depending on whether you're doing a beta or a bugfix release, you'll
 
108
   have to create a NEWS section for your release in the right
 
109
   place. Most of the time, the new section is at the top of the file
 
110
   (look what have been done for the various 2.0x and 2.1.0bx releases).
 
111
   The rule is to keep the sections sorted by date. You'll need to be
 
112
   cautious when merging back to trunk to respect that.
 
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
 
112
123
#. Summarize into one or two paragraphs what's new in this release.
113
124
 
114
125
#. Commit these changes to the release branch, using a command like::
115
 
    
116
 
     bzr commit -m "Release 1.14." 
117
 
   
 
126
 
 
127
     bzr commit -m "Release 1.14."
 
128
 
118
129
   The diff before you commit will be something like::
119
130
 
120
131
     === modified file 'NEWS'
121
132
     --- NEWS        2008-09-17 23:09:18 +0000
122
133
     +++ NEWS        2008-09-23 16:14:54 +0000
123
134
     @@ -4,6 +4,23 @@
124
 
     
 
135
 
125
136
      .. contents::
126
 
     
 
137
 
127
138
     +bzr 1.7 2008-09-23
128
139
     +------------------
129
140
     +
136
147
     +
137
148
      bzr 1.7rc2 2008-09-17
138
149
      ---------------------
139
 
     
140
 
     
 
150
 
 
151
 
141
152
     === modified file 'bzrlib/__init__.py'
142
153
     --- bzrlib/__init__.py  2008-09-16 21:39:28 +0000
143
154
     +++ bzrlib/__init__.py  2008-09-23 16:14:54 +0000
144
155
     @@ -41,7 +41,7 @@
145
156
      # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
146
157
      # releaselevel of 'dev' for unreleased under-development code.
147
 
     
 
158
 
148
159
     -version_info = (1, 7, 0, 'candidate', 2)
149
160
     +version_info = (1, 7, 0, 'final', 0)
150
 
     
151
 
     
 
161
 
 
162
 
152
163
      # API compatibility version: bzrlib is currently API compatible with 1.7.
153
 
      
 
164
 
154
165
#. Tag the new release::
155
166
 
156
167
     bzr tag bzr-1.14
159
170
   the Internet. PQM will pull from this repository when it attempts to merge
160
171
   your changes. Then submit those changes to PQM for merge into the
161
172
   appropriate release branch::
162
 
 
 
173
 
163
174
     bzr push
164
175
     bzr pqm-submit -m "(mbp) prepare 1.14"
165
176
 
170
181
-------------------------
171
182
 
172
183
#. Change into the source directory and run ::
173
 
  
 
184
 
174
185
     make dist
175
186
 
176
187
#. Now we'll try expanding this tarball and running the test suite
177
188
   to check for packaging problems::
178
 
 
 
189
 
179
190
     make check-dist-tarball
180
191
 
181
192
   You may encounter failures while running the test suite caused
248
259
   ``bazaar-announce`` list too.
249
260
 
250
261
   For final releases, it should also be cc'd to ``info-gnu@gnu.org``,
251
 
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.  
 
262
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.
252
263
 
253
264
   In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
254
265
   so that people who reply to the announcement don't spam other lists.
255
266
 
256
267
   The announce mail will look something like this::
257
 
   
 
268
 
258
269
      Subject: bzr x.yy released!
259
 
      
 
270
 
260
271
      <<Summary paragraph from news>>
261
 
     
262
 
      The Bazaar team is happy to announce availability of a new 
 
272
 
 
273
      The Bazaar team is happy to announce availability of a new
263
274
      release of the bzr adaptive version control system.
264
275
      Bazaar is part of the GNU system <http://gnu.org/>.
265
 
     
 
276
 
266
277
      Thanks to everyone who contributed patches, suggestions, and
267
278
      feedback.
268
 
      
269
 
      Bazaar is now available for download from 
270
 
      http://bazaar-vcs.org/Download as a source tarball; packages 
 
279
 
 
280
      Bazaar is now available for download from
 
281
      http://bazaar-vcs.org/Download as a source tarball; packages
271
282
      for various systems will be available soon.
272
 
      
 
283
 
273
284
      <<NEWS section from this release back to the last major release>>
274
285
 
275
286
   Feel free to tweak this to your taste.
280
291
   ensuring the new topic text keeps the project name, web site link, etc.
281
292
 
282
293
#. Announce on http://freshmeat.net/projects/bzr/
283
 
   
 
294
 
284
295
   This should be done for beta releases, release candidates and final
285
296
   releases. If you do not have a Freshmeat account yet, ask one of the
286
297
   existing admins.
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
--------