← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
 
1
Releasing Bazaar
 
2
================
 
3
 
 
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 
 
6
`overall development cycle <http://doc.bazaar-vcs.org/developers/cycle.html>`_,
 
7
but it's the most complex part.
 
8
This document gives a checklist you can follow from start to end in one
 
9
go.
 
10
 
 
11
.. contents::
 
12
 
 
13
 
 
14
Preconditions
 
15
-------------
 
16
 
 
17
#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
 
18
 
 
19
     bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
 
20
 
 
21
 
 
22
Starting a cycle
 
23
----------------
 
24
 
 
25
To start a new release cycle:
 
26
 
 
27
#. Create a new series at <https://launchpad.net/bzr/+addseries>. There is one
 
28
   series for every *x.y* release.
 
29
 
 
30
#. Go to the series web page at <https://launchpad.net/bzr/2.0>
 
31
 
 
32
#. Create a new release at
 
33
   <https://launchpad.net/bzr/2.0/+addrelease> and add
 
34
   information about this release. We will not use it yet, but it
 
35
   will be available for targeting or nominating bugs.
 
36
 
 
37
#. We create a new pqm-controlled branch for this release series, by
 
38
   asking a Canonical sysadmin.  
 
39
   This branch means that from the first release beta or candidate onwards,
 
40
   general development continues on the trunk, and only
 
41
   specifically-targeted fixes go into the release branch.
 
42
 
 
43
#. Add milestones at <https://edge.launchpad.net/bzr/2.0/+addmilestone> to
 
44
   that series for the beta release, release candidate and the final release,
 
45
   and their expected dates.
 
46
 
 
47
#. Update the version number in the ``bzr`` script, and the
 
48
   ``bzrlib/__init__.py`` file.
 
49
 
 
50
#. Send mail to the list with the key dates, who will be the release
 
51
   manager, and the main themes or targeted bugs.  Ask people to nominate
 
52
   objectives, or point out any high-risk things that are best done early,
 
53
   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
#. Create a new milestone at <https://launchpad.net/bzr/2.0/+addmilestone>
 
63
   for the beta release or release candidate.
 
64
 
 
65
#. Make a beta release or release candidate.
 
66
 
 
67
Preparing the tree for release
 
68
------------------------------
 
69
 
 
70
#. Make a local branch for preparing this release.  (Only for the first 
 
71
   release in a series, otherwise you should already have a branch.) ::
 
72
 
 
73
     bzr branch trunk prepare-1.14
 
74
 
 
75
#. Configure pqm-submit for this branch, with a section like this in
 
76
   ``~/.bazaar/locations.conf``::
 
77
 
 
78
        [/home/mbp/bzr/prepare-1.14]
 
79
        pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
 
80
        submit_branch = lp:bzr/2.0
 
81
        public_branch = http://bazaar.example.com/prepare-2.0
 
82
        submit_to = bazaar@lists.canonical.com
 
83
        smtp_server = mail.example.com:25
 
84
 
 
85
    Please see <http://doc.bazaar-vcs.org/developers/HACKING.html#an-overview-of-pqm>
 
86
    for more details on PQM
 
87
 
 
88
#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
 
89
   Double check that ./bzr ``_script_version`` matches ``version_info``. Check
 
90
   the output of ``bzr --version``.
 
91
 
 
92
   For beta releases use::
 
93
 
 
94
       version_info = (2, 1, 0, 'beta', 1)
 
95
 
 
96
 
 
97
   For release candidates use::
 
98
 
 
99
       version_info = (2, 0, 1, 'candidate', 1)
 
100
 
 
101
 
 
102
#. Add the date and release number to ``./NEWS``
 
103
 
 
104
#. To check that all bugs mentioned in ``./NEWS`` are actually marked as
 
105
   closed in Launchpad, you can run ``tools/check-newsbugs.py``::
 
106
 
 
107
     ./tools/check-newsbugs.py NEWS
 
108
 
 
109
   (But note there can be some false positives, and this script may be
 
110
   flaky <https://bugs.edge.launchpad.net/bzr/+bug/354985>.  Don't let
 
111
   this slow you down too much.)
 
112
 
 
113
#. Summarize into one or two paragraphs what's new in this release.
 
114
 
 
115
#. Commit these changes to the release branch, using a command like::
 
116
    
 
117
     bzr commit -m "Release 1.14." 
 
118
   
 
119
   The diff before you commit will be something like::
 
120
 
 
121
     === modified file 'NEWS'
 
122
     --- NEWS        2008-09-17 23:09:18 +0000
 
123
     +++ NEWS        2008-09-23 16:14:54 +0000
 
124
     @@ -4,6 +4,23 @@
 
125
     
 
126
      .. contents::
 
127
     
 
128
     +bzr 1.7 2008-09-23
 
129
     +------------------
 
130
     +
 
131
     +This release includes many bug fixes and a few performance and feature
 
132
     +improvements.  ``bzr rm`` will now scan for missing files and remove them,
 
133
     +like how ``bzr add`` scans for unknown files and adds them. A bit more
 
134
     +polish has been applied to the stacking code. The b-tree indexing code has
 
135
     +been brought in, with an eye on using it in a future repository format.
 
136
     +There are only minor installer changes since bzr-1.7rc2.
 
137
     +
 
138
      bzr 1.7rc2 2008-09-17
 
139
      ---------------------
 
140
     
 
141
     
 
142
     === modified file 'bzrlib/__init__.py'
 
143
     --- bzrlib/__init__.py  2008-09-16 21:39:28 +0000
 
144
     +++ bzrlib/__init__.py  2008-09-23 16:14:54 +0000
 
145
     @@ -41,7 +41,7 @@
 
146
      # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
 
147
      # releaselevel of 'dev' for unreleased under-development code.
 
148
     
 
149
     -version_info = (1, 7, 0, 'candidate', 2)
 
150
     +version_info = (1, 7, 0, 'final', 0)
 
151
     
 
152
     
 
153
      # API compatibility version: bzrlib is currently API compatible with 1.7.
 
154
      
 
155
#. Tag the new release::
 
156
 
 
157
     bzr tag bzr-1.14
 
158
 
 
159
#. Push those changes to a bzr reposistory that is public and accessible on
 
160
   the Internet. PQM will pull from this repository when it attempts to merge
 
161
   your changes. Then submit those changes to PQM for merge into the
 
162
   appropriate release branch::
 
163
 
 
164
     bzr push
 
165
     bzr pqm-submit -m "(mbp) prepare 1.14"
 
166
 
 
167
#. When PQM succeeds, pull down the master release branch.
 
168
 
 
169
 
 
170
Making the source tarball
 
171
-------------------------
 
172
 
 
173
#. Change into the source directory and run ::
 
174
  
 
175
     make dist
 
176
 
 
177
   This also makes a zip file, which is easier to access on Microsoft
 
178
   Windows.
 
179
 
 
180
#. Now we'll try expanding this tarball and running the test suite
 
181
   to check for packaging problems::
 
182
 
 
183
     make check-dist-tarball
 
184
 
 
185
   You may encounter failures while running the test suite caused
 
186
   by your locally installed plugins. Use your own judgment to
 
187
   decide if you can release with these failures. When in doubt,
 
188
   disable the faulty plugins one by one until you get no more
 
189
   failures.
 
190
 
 
191
 
 
192
Publishing the release
 
193
----------------------
 
194
 
 
195
Now you have the beta or releasable product.  The next step is making it
 
196
available to the world.
 
197
 
 
198
go to the release
 
199
 
 
200
#. Within that release, upload the source tarball and zipfile and the GPG
 
201
   signature.  Or, if you prefer, use the
 
202
   ``tools/packaging/lp-upload-release`` script to do this.
 
203
 
 
204
#. Link from http://bazaar-vcs.org/Download to the tarball and signature.
 
205
 
 
206
#. Announce on the `Bazaar home page <http://bazaar-vcs.org/>`_.
 
207
 
 
208
#. Check that the documentation for this release is available in
 
209
   <http://doc.bazaar-vcs.org>.  It should be automatically build when the
 
210
   branch is created, by a cron script ``update-bzr-docs`` on
 
211
   ``escudero``. As of today (2009-08-27) ``igc`` manually updates the
 
212
   pretty version of it.
 
213
 
 
214
 
 
215
Announcing the release
 
216
----------------------
 
217
 
 
218
Now that the release is publicly available, tell people about it.
 
219
 
 
220
#. Make an announcement mail.
 
221
 
 
222
   For release candidates or beta releases, this is sent to the ``bazaar``
 
223
   list only to inform plugin authors and package or installer managers.
 
224
 
 
225
   Once the installers are available, the mail can be sent to the
 
226
   ``bazaar-announce`` list too.
 
227
 
 
228
   For final releases, it should also be cc'd to ``info-gnu@gnu.org``,
 
229
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.  
 
230
 
 
231
   In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
 
232
   so that people who reply to the announcement don't spam other lists.
 
233
 
 
234
   The announce mail will look something like this::
 
235
   
 
236
      Subject: bzr x.yy released!
 
237
      
 
238
      <<Summary paragraph from news>>
 
239
     
 
240
      The Bazaar team is happy to announce availability of a new 
 
241
      release of the bzr adaptive version control system.
 
242
      Bazaar is part of the GNU system <http://gnu.org/>.
 
243
     
 
244
      Thanks to everyone who contributed patches, suggestions, and
 
245
      feedback.
 
246
      
 
247
      Bazaar is now available for download from 
 
248
      http://bazaar-vcs.org/Download as a source tarball; packages 
 
249
      for various systems will be available soon.
 
250
      
 
251
      <<NEWS section from this release back to the last major release>>
 
252
 
 
253
   Feel free to tweak this to your taste.
 
254
 
 
255
#. Make an announcement through <https://launchpad.net/bzr/+announce>
 
256
 
 
257
#. Update the IRC channel topic. Use the ``/topic`` command to do this,
 
258
   ensuring the new topic text keeps the project name, web site link, etc.
 
259
 
 
260
#. Announce on http://freshmeat.net/projects/bzr/
 
261
   
 
262
   This should be done for beta releases, release candidates and final
 
263
   releases. If you do not have a Freshmeat account yet, ask one of the
 
264
   existing admins.
 
265
 
 
266
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
 
267
   be done for final releases but not for beta releases or Release Candidates.
 
268
 
 
269
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
 
270
   done by running ::
 
271
 
 
272
       python setup.py register
 
273
 
 
274
   Remember to check the results afterwards.
 
275
 
 
276
   To be able to register the release you must create an account on
 
277
   <http://pypi.python.org/pypi> and have one of the existing owners of
 
278
   the project add you to the group.
 
279
 
 
280
 
 
281
Merging the released code back to trunk
 
282
---------------------------------------
 
283
 
 
284
Merge the release branch back into the trunk.  Check that changes in NEWS
 
285
were merged into the right sections.  If it's not already done, advance
 
286
the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
 
287
back into pqm for bzr.dev.
 
288
 
 
289
You should also merge (not pull) the release branch into
 
290
``lp:~bzr/bzr/current``, so that branch contains the current released code
 
291
at any time.
 
292
 
 
293
 
 
294
See also
 
295
--------
 
296
 
 
297
* `Packaging into the bzr PPA <ppa.html>`_ to make and publish Ubuntu
 
298
  packages.
 
299
* `Bazaar Developer Document Catalog <index.html>`_
 
300
* `Development cycles <cycle.html>`_: things that happen during the cycle
 
301
  before the actual release.
 
302
 
 
303
..
 
304
   vim: filetype=rst textwidth=74 ai shiftwidth=4