~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Jelmer Vernooij
  • Date: 2016-04-03 16:32:31 UTC
  • mto: This revision was merged to the branch mainline in revision 6617.
  • Revision ID: jelmer@jelmer.uk-20160403163231-h72bo0uyek2gikw0
Don't put French text in doc/en/user-reference when LANGUAGE=fr_CH.UTF_8.

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
6
 
the `overall development cycle
7
 
<http://doc.bazaar.canonical.com/developers/cycle.html>`_, (go re-read
8
 
this document to ensure it hasn't been updated) but it's the most
9
 
complex part.  This document gives a checklist you can follow from start
10
 
to end in one go.
 
5
release, and managing the release process.  This is just one phase of the
 
6
`overall development cycle
 
7
<http://doc.bazaar.canonical.com/developers/cycle.html>`_, (go re-read this
 
8
document to ensure it hasn't been updated since you last read it) but it's
 
9
the most complex part.
 
10
 
 
11
If you're doing your first release you can follow this document and read
 
12
each step explanation. It's also a good practice to read it for any release
 
13
to ensure you don't miss a step and to update it as the release process
 
14
evolves.
11
15
 
12
16
If you're helping the Release Manager (RM) for one reason or another, you
13
17
may notice that he didn't follow that document scrupulously. He may have
14
18
good reasons to do that but he may also have missed some parts.
15
19
 
16
 
Follow the document yourself and don't hesitate to create the missing
17
 
milestones for example (we tend to forget these ones a lot).
18
 
 
19
20
.. contents::
20
21
 
21
22
 
22
23
Preconditions
23
24
=============
24
25
 
 
26
#. PQM access rights (or you won't be able to land any change)
 
27
 
25
28
#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
26
29
 
27
30
     bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
28
31
 
 
32
#. Alternatively, you can download and install ``lp:hydrazine`` (the main
 
33
   difference is that hydrazine requires the branch to land to be hosted on
 
34
   launchpad).
 
35
 
 
36
What do we release
 
37
==================
 
38
 
 
39
In this document, we're talking about source releases only, packages and
 
40
installers are built from this but we won't talk about them here.
 
41
 
 
42
Every release is part of a series, ``bzr-2.4.1`` is part of series ``2.4``.
 
43
 
 
44
We do two different kind of releases: the betas releases and the stable
 
45
releases for a given series.
 
46
 
 
47
For a given series, releases will be done to deliver new versions of bzr to
 
48
different kinds of users:
 
49
 
 
50
#. beta releases: named ``x.ybn`` where ``x.y`` is the series and ``n``
 
51
   starts at 1 and is incremented. These releases are targeted to beta
 
52
   testers who don't want to run from source but are interested in features
 
53
   or improvements.
 
54
 
 
55
#. stable releases: name ``x.y.z`` where ``x.y.`` is the series and ``z``
 
56
   starts at 0 and is incremented. These releases are targeted at people
 
57
   that want bugfixes only and no new features.
 
58
 
 
59
 
 
60
Differences in the release process between beta and stable release will be
 
61
mentioned when needed.
29
62
 
30
63
When do we relase ?
31
64
===================
32
65
 
33
 
As of October 2010, we mantain four series.  Concurrently releasing them
34
 
all at the same time makes it harder to shorten the delay between the
35
 
source availability and the package building longer than necessary (we
36
 
delay the official announcement until most of our users can install the new
37
 
release).
 
66
As of July 2011, we maintain four series (and one that is about to be EOLed).
 
67
Concurrently releasing them all at the same time makes it harder to shorten
 
68
the delay between the source availability and the package building longer
 
69
than necessary (we delay the official announcement until most of our users
 
70
can install the new release).
38
71
 
39
72
In order to continue to do time-based releases, we need to plan the
40
73
releases by series to minimize the collisions. In the end, it's the Release
41
74
Manager call to decide whether he prefers to do all releases at once
42
75
though, so the rules presented here are a conservative approach.
43
76
 
44
 
We want to respect the following rules::
45
 
 
46
 
 #. as much as possible releases should not disturb development, and
47
 
    ongoing development should not disturb releases,
48
 
 
49
 
 #. the most recent development series should release once a month during
50
 
    the beta period (see `Development cycles <cycle.html>`_ for more
51
 
    details),
52
 
 
53
 
 #. the most recent stable series should release every other month (based
54
 
    on the amount of bug fixes, this can be shorter or longer depending on
55
 
    the bugs importance),
56
 
 
57
 
 #. previous series should relesase on a regular basis without interfering
58
 
    with the most recent series with a decreasing order of priority (again
59
 
    this should be based on bugs importance and user feedback),
60
 
 
61
 
 #. the death of a series should be planned ahead of time. 6 months should
62
 
    give enough time to our users to migrate to a more recent series. This
63
 
    doesn't mean we will make a release at the end of the series, just that
64
 
    before the end date we _could_ possibly put out another release if
65
 
    there was a sufficiently important fix.  Beyond that date, we won't
66
 
    even land changes on that branch (unless something causes a miraculous
67
 
    resurrection.)
68
 
 
69
 
 #. there should not be more than 2 releases in the same week (but the
70
 
    Release Manager is free to ignore this (get in touch with packagers
71
 
    though),
72
 
 
73
 
 #. the series are aligned with Ubuntu releases for convenience since we
74
 
    create a new series every 6 months. This means that we support the
75
 
    stable series for 18 months. Note that we also propose the most recent
76
 
    stable series via the ppa, so whether we keep supporting LTS directly
77
 
    or via the ppa is still an open question.
78
 
 
 
77
We want to respect the following rules:
 
78
 
 
79
#. as much as possible releases should not disturb development, and
 
80
   ongoing development should not disturb releases,
 
81
 
 
82
#. the most recent development series should release once a month during
 
83
   the beta period (see `Development cycles <cycle.html>`_ for more
 
84
   details),
 
85
 
 
86
#. the most recent stable series should release every other month (based
 
87
   on the amount of bug fixes, this can be shorter or longer depending on
 
88
   the bugs importance),
 
89
 
 
90
#. previous series should release on a regular basis without interfering
 
91
   with the most recent series with a decreasing order of priority (again
 
92
   this should be based on bugs importance and user feedback),
 
93
 
 
94
#. the death of a series should be planned ahead of time. 6 months should
 
95
   give enough time to our users to migrate to a more recent series. This
 
96
   doesn't mean we will make a release at the end of the series, just that
 
97
   before the end date we *could* possibly put out another release if
 
98
   there was a sufficiently important fix.  Beyond that date, we won't
 
99
   even land changes on that branch (unless something causes a miraculous
 
100
   resurrection.)
 
101
 
 
102
#. there should not be more than 2 releases in the same week (but the
 
103
   Release Manager is free to ignore this (get in touch with packagers
 
104
   though),
 
105
 
 
106
#. the series are aligned with Ubuntu releases for convenience since we
 
107
   create a new series every 6 months. This means that we support the
 
108
   stable series for 18 months. Note that we also propose the most recent
 
109
   stable series via the stable PPA but that the SRU processs allow us to
 
110
   reach a wider audience.
 
111
 
 
112
At the start of a series cycle
 
113
==============================
 
114
 
 
115
To start a new series cycle:
 
116
 
 
117
#. Create a new series ``x.y`` at <https://launchpad.net/bzr/+addseries>.
 
118
 
 
119
#. Add milestones at <https://launchpad.net/bzr/x.y/+addmilestone> to that
 
120
   series for the beta releases and the stable series mentioning their
 
121
   expected dates. Only the milestone associated to the next release in
 
122
   this series should be left active to avoid clutter when targeting bugs.
 
123
 
 
124
#. If you made a new series, you will need to create a new pqm-controlled
 
125
   branch for this release series. This branch will be used only from the
 
126
   first non-beta release onwards. It needs to be created by a Canonical
 
127
   sysadmin (ask the core devs for instructions or to do it for you).
 
128
 
 
129
#. Start a new release-notes file::
 
130
 
 
131
       cd doc/en/release-notes
 
132
       cp series-template.txt bzr-x.y.txt  # e.g. bzr-2.3.txt
 
133
       bzr add bzr-x.y.txt
 
134
 
 
135
#. Start a new whats-new file::
 
136
 
 
137
       cd doc/en/whats-new
 
138
       cp template.txt bzr-x.y.txt  # e.g. bzr-2.6.txt
 
139
       bzr add bzr-x.y.txt
 
140
 
 
141
#. Update ``doc/en/index.txt`` to point to the new whats-new file.
79
142
 
80
143
At the start of a release cycle
81
144
===============================
82
145
 
83
146
To start a new release cycle:
84
147
 
85
 
#. If this is the first release for a given *x.y* then create a new
86
 
   series at <https://launchpad.net/bzr/+addseries>. There is one series
87
 
   for every *x.y* release.
88
 
 
89
 
#. If you made a new series, create a new pqm-controlled branch for this
90
 
   release series, by asking a Canonical sysadmin.  This branch means that
91
 
   from the first release beta or candidate onwards, general development
92
 
   continues on the trunk, and only specifically-targeted fixes go into
93
 
   the release branch.
94
 
 
95
 
#. If you made a new series, add milestones at
96
 
   <https://launchpad.net/bzr/x.y/+addmilestone> to that series for
97
 
   the beta release, release candidate and the final release, and their
98
 
   expected dates.
99
 
 
100
 
#. Create a new milestone <https://launchpad.net/bzr/x.y/+addmilestone>
101
 
   and add information about this release.  We will not use it yet, but it
102
 
   will be available for targeting or nominating bugs.
103
 
 
104
148
#. Send mail to the list with the key dates, who will be the release
105
149
   manager, and the main themes or targeted bugs.  Ask people to nominate
106
150
   objectives, or point out any high-risk things that are best done early,
107
151
   or that interact with other changes. This is called the metronome mail
108
152
   and is described in `Development cycles <cycle.html>`_.
109
153
 
110
 
#. Make a local branch for preparing this release.  (Only for the first
111
 
   release in a series, otherwise you should already have a branch.) ::
112
 
 
113
 
     bzr branch trunk prepare-1.14
 
154
#. Make a local branch to prepare the release::
 
155
 
 
156
        bzr branch lp:bzr/x.y x.y-dev
 
157
 
 
158
   If you're doing your first beta release, branch from trunk::
 
159
 
 
160
       bzr branch lp:bzr x.y-dev
 
161
 
 
162
   Note that you will generally reuse the same branch for all releases in a
 
163
   given series.
114
164
 
115
165
#. Configure pqm-submit for this branch, with a section like this (where
116
 
   x.y is the version to release). **Or use hydrazine for easy use**
117
 
   ``~/.bazaar/locations.conf``::
 
166
   ``x.y`` is the series for your release). **Or use hydrazine for easier
 
167
   setup** ``~/.bazaar/locations.conf``::
118
168
 
119
 
        [/home/mbp/bzr/prepare-x.y]
 
169
        [/home/mbp/bzr/x.y-dev]
120
170
        pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
121
171
        submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
122
172
        parent_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
123
 
        public_branch = http://bazaar.example.com/prepare-x.y
 
173
        public_branch = http://bazaar.example.com/x.y-dev
124
174
        submit_to = bazaar@lists.canonical.com
125
175
        smtp_server = mail.example.com:25
126
176
 
132
182
   
133
183
       version_info = (x, y, z, 'dev', 0)
134
184
   
135
 
#. If you made a new series, then start a new release-notes file::
136
 
 
137
 
       cd doc/en/release-notes
138
 
       cp series-template.txt bzr-x.y.txt  # e.g. bzr-2.3.txt
139
 
       bzr add bzr-x.y.txt
140
 
 
141
185
#. Add a new section at the top of the current release notes (in
142
186
   ``doc/en/release-notes``) about the new release, including its version
143
187
   number and the headings from ``release-template.txt``.
144
188
 
145
189
#. Update the "What's New" documents in ``doc/en/whats-new``.
146
190
 
 
191
#. Make sure a milestone exists for your release and that it is active,
 
192
   <https://launchpad.net/bzr/x.y> lists the existing milestones,
 
193
   <https://launchpad.net/bzr/x.y/x.y.z/+edit> allows you to toggle the
 
194
   active flag.
 
195
 
147
196
#. Commit this and send it to PQM.
148
197
 
149
198
 
158
207
   also mail the list to raise this issue in our process. Milestones are
159
208
   found at <https://launchpad.net/bzr/+milestone/x.y.z>.
160
209
 
 
210
#. Merge into your branch all previous stable series fixes that haven't been
 
211
   merged yet. For example, if you're releasing 2.6.x, make sure the fixes
 
212
   on 2.5, 2.4, 2.3, etc have already been merged up::
 
213
 
 
214
     bzr merge lp:bzr/2.4
 
215
 
 
216
   and commit that merge in its own commit. This should happen only if the
 
217
   devs landing changes in previous releases forgot to merge them up. Since
 
218
   this can slow down the freeze, feel free to gently remind them about
 
219
   their duties ;) If you feel unsafe resolving the conflicts or it's too
 
220
   time consuming, contact the related devs and skip this merge.
 
221
 
161
222
#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
162
223
   Make sure the corresponding milestone exists.
163
224
   Double check that ./bzr ``_script_version`` matches ``version_info``. Check
164
 
   the output of ``bzr --version``.
 
225
   the output of ``./bzr --version``.
165
226
 
166
227
   For beta releases use::
167
228
 
168
 
       version_info = (2, 1, 0, 'beta', SERIAL)
169
 
 
170
 
   For instance 2.1b1::
171
 
 
172
 
       version_info = (2, 1, 0, 'beta', 1)
173
 
 
174
 
   For release candidates use::
175
 
 
176
 
       version_info = (2, 0, 1, 'candidate', SERIAL)
 
229
       version_info = (2, 6, 0, 'beta', SERIAL)
 
230
 
 
231
   For instance 2.6b1::
 
232
 
 
233
       version_info = (2, 6, 0, 'beta', 1)
177
234
 
178
235
   For stable releases use::
179
236
 
180
 
       version_info = (2, 1, 2, 'final', 0)
 
237
       version_info = (2, 6, 0, 'final', 0)
181
238
 
182
239
#. Update the ``./doc/en/release-notes/`` section for this release.
183
240
 
 
241
   Check that all news entries related to this release have been added in
 
242
   the right section. For example, if you're releasing 2.6b2, the following
 
243
   command should display a a single chuk diff for the 2.6b2 release::
 
244
 
 
245
     bzr diff -rbzr-2.6b2.. doc/en/release-notes/bzr-2.6.txt
 
246
 
184
247
   Fill out the date and a description of the release under the existing
185
 
   header. If there isn't one, follow the instructions above for using the
186
 
   ``release-template.txt`` file.
187
 
 
188
 
   See *2.1.1* or similar for an example of what this looks like.
189
 
 
190
 
#. Add a summary of the release into the "What's New" document.
 
248
   header (the diff above will help you summarizing). If there isn't one,
 
249
   follow the instructions above for using the ``release-template.txt`` file
 
250
   and remind people that they should document their changes there ;)
 
251
 
 
252
   See *2.6b1* or similar for an example of what this looks like.
 
253
 
 
254
#. Add or check the summary of the release into the "What's New" document.
 
255
 
 
256
  If this is the first release in a new series make sure to update the
 
257
  introduction mentioning:
 
258
 
 
259
  * the date of this first release,
 
260
  * until when the series is expected to be supported.
 
261
 
 
262
  Looking at ``bzr annotate`` for previous series should give you the right
 
263
  hints. The ``doc/en/_templates/index.html`` file should also be updated.
191
264
 
192
265
#. To check that all bugs mentioned in the release notes are actually
193
266
   marked as closed in Launchpad, you can run
195
268
 
196
269
     ./tools/check-newsbugs.py doc/en/release-notes/bzr-x.y.txt
197
270
 
198
 
   As of 2011-05-26, only a few false positives remain in the older
199
 
   series. Don't let this slow you down too much. This script accepts
200
 
   options you may find useful, use ``./tools/check-newsbugs.py`` to display
201
 
   its usage.
 
271
   As of 2011-07-18, all bugs mentioned in the output of the script requires
 
272
   some sort of intervention (either changing the status if it's not 'Fix
 
273
   Released' or setting a different milestone if the bug hasn't been
 
274
   fixed). A few false positives may remain in the older series, don't let
 
275
   this slow you down too much. This script accepts options you may find
 
276
   useful, use ``./tools/check-newsbugs.py`` to display its usage (``-w``
 
277
   will open each bug in your browser for example).
 
278
 
 
279
#. For beta releases update the translation template::
 
280
 
 
281
     BZR_PLUGIN_PATH=-site make po/bzr.pot
 
282
 
 
283
   This is especially important for the final beta release which is when
 
284
   translations are frozen and translators are requested (see `The final
 
285
   beta - branching and translations`_) to make the translations.
 
286
 
 
287
#. For stable releases update the translations::
 
288
 
 
289
     bzr merge lp:~bzr-core/bzr/bzr-translations-export-x.y
202
290
 
203
291
#. Commit these changes to the release branch, using a command like::
204
292
 
274
362
 
275
363
#. Tag the new release::
276
364
 
277
 
     bzr tag bzr-2.3.1
 
365
     bzr tag bzr-2.6.0
278
366
 
279
 
#. Push those changes to a bzr repository that is public and accessible on
280
 
   the Internet. PQM will pull from this repository when it attempts to merge
281
 
   your changes. Then submit those changes to PQM for merge into the
282
 
   appropriate release branch::
 
367
#. Push those changes to a bzr branch that is public and accessible on the
 
368
   Internet. PQM will pull from this branch when it attempts to merge your
 
369
   changes. Then submit those changes to PQM for merge into the appropriate
 
370
   release branch::
283
371
 
284
372
     bzr push
285
 
     bzr pqm-submit -m "(vila) Release 2.3.1 (Vincent Ladeuil)"
 
373
     bzr pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
 
374
 
 
375
   Note that ``bzr push`` should mention updating one tag (which you just
 
376
   created). If it doesn't, double-check that you created (and pushed) this
 
377
   tag.
286
378
 
287
379
   Or with hydrazine::
288
380
 
311
403
   ``BZR_DISABLE_PLUGINS`` or ``BZR_PLUGIN_PATH=-site`` to disable one or
312
404
   all plugins.
313
405
 
 
406
   Until <http://pad.lv/839461> is fixed, you may encounter issues if you
 
407
   cut a release for old stable branches (<= 2.2) and use a more recent
 
408
   OS/distro. If that's the case, check the bug status and use the following
 
409
   workaround if no fix is available::
 
410
 
 
411
     export TTPATH=<local branch of lp:testtools -r 0.9.2>
 
412
     export SUPATH=<local branch of lp:subunit -r 0.0.6>
 
413
     PYTHONPATH=$TTPATH:$SUPATH/python PATH=$SUPATH/filters:${PATH} BZR_PLUGIN_PATH=-site make check-dist-tarball PYTHON=python2.6 | subunit2pyunit
 
414
 
314
415
   Remember that PQM has just tested everything too, this step is
315
416
   particularly testing that the pyrex extensions, which are updated
316
417
   by your local pyrex version when you run make dist, are in good
320
421
Publishing the source tarball
321
422
-----------------------------
322
423
 
323
 
#. Go to the relevant series page in Launchpad.
 
424
#. Go to the relevant <https://launchpad.net/bzr/x.y> series page in Launchpad.
324
425
 
325
426
#. Create a release of the milestone, and upload the source tarball and
326
427
   the GPG signature.  Or, if you prefer, use the
331
432
   <https://bugs.launchpad.net/launchpad/+bug/586445>
332
433
 
333
434
 
334
 
Announcing the source freeze
335
 
----------------------------
336
 
 
337
 
#. Post to the ``bazaar`` list, saying that the source has been frozen
338
 
   (gone gold). Be extra clear that this is only a *source* release
339
 
   targeted at packagers and installer builders (see
340
 
   <https://bugs.launchpad.net/launchpad/+bug/645084>).  This is the cue
341
 
   for platform maintainers and plugin authors to update their code.  This
342
 
   is done before the general public announcement of the release.
343
 
 
344
 
 
345
435
Kick off the next cycle
346
436
-----------------------
347
437
 
348
 
#. To let developers work on the next release, do
349
 
   `At the start of a release cycle` now.
350
 
 
351
 
#. Pause for a few days.
 
438
From that point, there is no possible return, the tarball has been uploaded
 
439
so you can relax a bit.
 
440
 
 
441
You're still holding a "social" lock on the launchpad branch though. Until
 
442
your start the next cycle, nobody should land anything on this branch. If
 
443
they do, they either targeted the wrong branch or didn't update the news
 
444
file correctly, so the sooner the branch is opened again, the better.
 
445
 
 
446
This matters more for ``lp:bzr`` than for ``lp:bzr/x.y``, ``lp:bzr`` should
 
447
always be open for landing, so you should do `At the start of a release
 
448
cycle`_ as soon as possible (i.e. update the version number in ``bzr`` and
 
449
``bzrlib/__init__``, create/update the news files and create/update the
 
450
milestone for the next relase).
 
451
 
 
452
You may also need to do `At the start of a series cycle`_ if you're starting
 
453
a new series.
 
454
 
 
455
The final beta - branching and translations
 
456
-------------------------------------------
 
457
 
 
458
A word of caution: the instructions above works well for all releases but
 
459
there is one special case that requires a bit more care: when you release
 
460
the *last* beta for a given ``x.y`` series (from trunk aka lp:bzr), you need
 
461
to setup *two* branches for the next cycle:
 
462
 
 
463
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``.
 
464
 
 
465
#. ``lp:bzr/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
 
466
   series. Since this is first real use of ``lp:bzr/x.y``, this is also the
 
467
   deadline for the PQM branch to be created.
 
468
 
 
469
Both are important as ``lp:bzr`` should remain open so any change can be
 
470
landed, ``lp:bzr/x.y`` on the other hand should be ready to receive bug
 
471
fixes.
 
472
 
 
473
``lp:bzr`` is generally more important as the bug fixes on ``lp:bzr/x.y``
 
474
won't be released sooner than a month from now whereas people may already
 
475
been waiting to land on ``lp:bzr``.
 
476
 
 
477
In a nutshell:
 
478
 
 
479
#. Open ``lp:bzr`` for ``x.(y+1)``
 
480
 
 
481
#. Create or update the ``x.y`` PQM branch based on whatever revision you
 
482
   want to release. Since it takes time to create the PQM branch for the new
 
483
   series you should plan to get it created a few days before you need it
 
484
   and seed it with the revision from trunk you want to base your release of
 
485
   (ask a LOSA for pulling this revision from trunk and pushing it to the
 
486
   series branch (``lp:bzr/x.y``) when you're ready).
 
487
 
 
488
#. Release ``x.y.0`` from ``lp:bzr/x.y``
 
489
 
 
490
#. Open ``lp:bzr/x.y`` for bug fixes
 
491
 
 
492
You also need to ensure Launchpad is set up to import/export translations
 
493
for the new branch and inform translators.
 
494
 
 
495
#. Push the last beta release to a new branch::
 
496
 
 
497
     bzr push lp:~bzr-core/bzr/bzr-translations-export-x.y
 
498
 
 
499
#. On the translations series synchronization settings page
 
500
   <https://translations.launchpad.net/bzr/x.y/+translations-settings>
 
501
   turn on ``Import template files`` then for exports click ``Choose a
 
502
   target branch`` and point it at the branch you just pushed.
 
503
 
 
504
#. E-mail translators to announce that the forthcoming stable release of bzr
 
505
   is ready for translations.  Send to
 
506
   ``launchpad-translators@lists.launchpad.net`` and
 
507
   ``ubuntu-translators@lists.ubuntu.com``.
 
508
 
 
509
#. The series is now frozen for strings and API, see below for adding
 
510
   that to the announcement.
 
511
 
 
512
Announcing the source freeze
 
513
----------------------------
 
514
 
 
515
#. Post to the ``bazaar@lists.canonical.com`` and
 
516
   ``bzr-packagers@list.launchpad.net`` lists, saying that the source has
 
517
   been frozen. Be extra clear that this is only a *source* release targeted
 
518
   at packagers and installer builders (see
 
519
   <https://bugs.launchpad.net/launchpad/+bug/645084>).  This is the cue for
 
520
   platform maintainers and plugin authors to update their code.  This is
 
521
   done before the general public announcement of the release.
 
522
 
 
523
   The freeze announcement generally guess the date of the official public
 
524
   announcement, for the most recent stable series (the one supported by the
 
525
   installers and most of the distributions) it's generally a few days after
 
526
   the freeze. For older series supported only via SRUs for Ubuntu, we don't
 
527
   control the process as tightly so guessing the date is not appropriate.
 
528
 
 
529
   For the final beta release include in your announcement a notice of
 
530
   API and translation freezes noting that public methods should not
 
531
   be removed or changed and strings should not be added or changed.
 
532
 
 
533
#. Pause for a few days. 
352
534
 
353
535
 
354
536
Publishing the release
355
537
----------------------
356
538
 
357
539
There is normally a delay of a few days after the source freeze to allow
358
 
for binaries to be built on various platforms.  Once they have been built,
 
540
for binaries to be built for various platforms. Once they have been built,
359
541
we have a releasable product.  The next step is to make it generally
360
542
available to the world.
361
543
 
362
544
#. Go to the release web page at <https://launchpad.net/bzr/x.y/x.y.z>
363
545
 
364
 
#. Announce on the `Bazaar website <http://bazaar.canonical.com/>`_.
365
 
   This page is edited via the lp:bzr-website branch. (Changes
 
546
#. Announce on the `Bazaar website <http://bazaar.canonical.com/>`_.  This
 
547
   page is edited in ``build.py`` in the lp:bzr-website branch. (Changes
366
548
   pushed to this branch are refreshed by a cron job on escudero.)
367
549
 
368
550
#. Check that the documentation for this release is available in
369
 
   <http://doc.bazaar.canonical.com>.  It should be automatically build when the
370
 
   branch is created, by a cron script ``update-bzr-docs`` on
371
 
   ``escudero``.
372
 
 
 
551
   <http://doc.bazaar.canonical.com>.  It should be automatically build when
 
552
   the branch is created, by a cron script ``update-bzr-docs`` on
 
553
   ``escudero``. When the first release is created in a new series, a branch
 
554
   needs to be created on zhongshan::
 
555
 
 
556
     ssh zhongshan.canonical.com
 
557
     sudo -u bzr-web -s
 
558
     cd /srv/doc.bazaar.canonical.com/
 
559
     bzr branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.6 bzr/bzr.2.6
 
560
 
 
561
   And the ``bzr/bin/update-bzr-docs`` script needs to refer to it.
 
562
 
 
563
   The ``lp:bzr-alldocs`` branch also needs to be updated when a new series
 
564
   is introduced, see the ``README`` file there for more instructions
 
565
   (looking at the branch history is also a good way to understand what
 
566
   needs to be done and to document any policy changes).
373
567
 
374
568
Announcing the release
375
569
----------------------
378
572
 
379
573
#. Make an announcement mail.
380
574
 
381
 
   For release candidates or beta releases, this is sent to the ``bazaar``
382
 
   list only to inform plugin authors and package or installer managers.
383
 
 
384
 
   Once the installers are available, the mail can be sent to the
385
 
   ``bazaar-announce`` list too.
386
 
 
387
 
   For final releases, it should also be cc'd to ``info-gnu@gnu.org``,
 
575
   For beta releases, this is sent to the ``bazaar@lists.canonical.com`` and
 
576
   ``bazaar-announce@lists.canonical.com`` lists.
 
577
 
 
578
   For stable releases (excluding SRUs which are for older stable releases),
 
579
   it should also be cc'd to ``info-gnu@gnu.org``,
388
580
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.
389
581
 
390
582
   In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
396
588
 
397
589
      The Bazaar team is happy to announce availability of a new
398
590
      release of the bzr adaptive version control system.
399
 
      Bazaar is part of the GNU system <http://gnu.org/>.
 
591
 
 
592
      Bazaar <http://bazaar.canonical.com/> is a Canonical project and part
 
593
      of the GNU project <http://gnu.org/> to produce a free operating
 
594
      system.
400
595
 
401
596
      <<Summary paragraph from news>>
402
597
 
412
607
   Feel free to tweak this to your taste.
413
608
 
414
609
#. Make an announcement through <https://launchpad.net/bzr/+announce>
415
 
 
416
 
#. Update the IRC channel topic. Use the ``/topic`` command to do this,
417
 
   ensuring the new topic text keeps the project name, web site link, etc.
418
 
 
419
 
#. Announce on http://freshmeat.net/projects/bzr/
420
 
 
421
 
   This should be done for beta releases, release candidates and final
422
 
   releases. If you do not have a Freshmeat account yet, ask one of the
423
 
   existing admins.
424
 
 
425
 
   The purpose here is to point users to the latest stable release while still
426
 
   publishing announcements for development releases.
 
610
   mentioning the milestone URL <https://launchpad.net/bzr/+milestone/x.y.z>
 
611
   so people get an easy access to details.
 
612
 
 
613
#. Announce on https://freecode.com/projects/bazaar-vcs
 
614
 
 
615
   This should be done for beta releases and stable releases. If you do not
 
616
   have a Freecode account yet, ask one of the existing admins.
 
617
 
 
618
   The purpose here is to point users to the latest stable release
 
619
   (i.e. SRUs are excluded) while still publishing announcements for beta
 
620
   releases.
427
621
 
428
622
   There are several kinds of modifications that could be done there via the
429
623
   ``Administration`` box in the lower right area of the page:
432
626
     ``Links`` box are edited. This should rarely change except for the URLs
433
627
     related to the latest stable release.
434
628
 
435
 
   * New announcement: When doing a release (beta, candidates, final), put the
436
 
     summary of the release (you can't embed URLs there, the moderation staff
437
 
     remove them). Users can still access the releases notes via the ``Release
438
 
     Notes`` URL in the ``Links`` box in the upper right area of the
439
 
     page. When doing the first stable release in a series, delete the
440
 
     ``Unstable installers`` <https://launchpad.net/bzr/x.y/x.ybn> and
441
 
     ``Unstable source tarball``
 
629
   * New announcement: When doing a release, put the summary of the release
 
630
     (you can't embed URLs there, the moderation staff remove them). Users
 
631
     can still access the releases notes via the ``Release Notes`` URL in
 
632
     the ``Links`` box in the upper right area of the page. When doing the
 
633
     first stable release in a series, delete the ``Unstable installers``
 
634
     <https://launchpad.net/bzr/x.y/x.ybn> and ``Unstable source tarball``
442
635
     <http://launchpad.net/bzr/x.y/x.ybn/+download/bzr-x.ybn.tar.gz>
443
 
     links. Conversely, when creating the first beta in a development series,
444
 
     create these links again. Check all links when doing other kinds of
445
 
     release.
446
 
 
447
 
   * Set direct download: When releasing a new stable release, this should
448
 
     point to the corresponding launchpad page:
449
 
     <https://launchpad.net/bzr/x.y/x.y.z/>
 
636
     links. Conversely, when creating the first beta in a development
 
637
     series, create these links again. Check all links when doing other
 
638
     kinds of release.
450
639
 
451
640
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
452
 
   be done for final releases but not for beta releases or Release Candidates.
 
641
   be done for the stable and beta releases.
453
642
 
454
643
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
455
644
   done by running ::
456
645
 
457
646
       python setup.py register
458
647
 
459
 
   Remember to check the results afterwards -- this should be done for
460
 
   final releases but not for beta releases or Release Candidates.
 
648
   Remember to check the results afterward -- this should be done for
 
649
   stable releases but not for beta releases nor SRUs.
461
650
 
462
651
   To be able to register the release you must create an account on
463
652
   <http://pypi.python.org/pypi> and have one of the existing owners of
467
656
Merging the released code back to trunk
468
657
---------------------------------------
469
658
 
470
 
Merge the release branch back into the trunk.  The
471
 
``doc/en/release-notes`` changes should be merged into the right place
472
 
because each release series has its own release-notes file, but
473
 
double-check.
 
659
Merge the release branch back into the trunk.  The ``doc/en/release-notes``
 
660
changes should be merged into the right place because each release series
 
661
has its own release-notes file, but double-check.
474
662
 
475
663
If it's not already done, advance the version number in ``bzr`` and
476
664
``bzrlib/__init__.py``.  Submit this back into pqm for bzr.dev.
479
667
created the corresponding milestone to ensure the continuity in bug
480
668
targeting or nominating. Depending on the change, you may even have to
481
669
create a new series (if your change the major or minor release number), in
482
 
that case go to `At the start of a release cycle` and follow the instructions from there.
 
670
that case go to `At the start of a series cycle`_ and follow the
 
671
instructions from there.
483
672
 
484
 
You should also merge (not pull) the release branch into
485
 
``lp:~bzr/bzr/current``, so that branch contains the current released code
486
 
at any time.
487
673
 
488
674
Releases until the final one
489
675
----------------------------
490
676
 
491
 
Congratulations - you have made your first release.  Have a beer
492
 
or fruit juice - it's on the house! If it was a beta, or
493
 
candidate, you're not finished yet. Another beta or candidate or
494
 
hopefully a final release is still to come.
 
677
Congratulations - you have made your first release.  Have a beer or fruit
 
678
juice - it's on the house! If it was a beta, you're not finished
 
679
yet. Another beta or hopefully a stable release is still to come.
495
680
 
496
 
The process is the same as for the first release. Goto `Doing a
497
 
particular release`_ and follow the instructions again. Some details change
498
 
between beta, candidate and final releases, but they should be
499
 
documented. If the instructions aren't clear enough, please fix them.
 
681
The process is the same as for the first release. Goto `Doing a particular
 
682
release`_ and follow the instructions again. Some details change between
 
683
beta and stable releases, but they should be documented. If the instructions
 
684
aren't clear enough, please fix them.
500
685
 
501
686
 
502
687
Getting the release into Ubuntu
515
700
the `SRU (Stable Release Updates)
516
701
<https://wiki.ubuntu.com/StableReleaseUpdates>`__ process.   
517
702
 
518
 
As of September 2010, bzr has applied to the technical board to be added
519
 
to the `MicroReleaseExceptions
 
703
Since September 2010, bzr has received approval by the technical
 
704
board for the `MicroReleaseExceptions
520
705
<https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions>`__
521
 
category so that whole bugfix releases can more easily be approved.
 
706
category so that whole bugfix releases can more easily be
 
707
approved.
 
708
 
 
709
Progress on these realeases is tracked on the `SRU wiki
 
710
<http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates>`_
 
711
page.
522
712
 
523
713
**After making a bzr stable-release release, nominate the most serious bug
524
714
for the appropriate Ubuntu release and subscribe the `ubuntu-sru` team.**
535
725
   button and select the right Ubuntu release. As of September 2010, this
536
726
   means:
537
727
 
 
728
  * ``quantal`` for the 2.6 series,
 
729
  * ``precise`` for the 2.5 series,
 
730
  * ``oneiric`` for the 2.4 series,
 
731
  * ``natty`` for the 2.3 series,
538
732
  * ``maverick`` for the 2.2 series,
539
733
  * ``lucid`` for the 2.1 series,
540
 
  * ``karmic`` for the 2.0 series.
541
734
 
542
735
 * Subscribe the ``~ubuntu-sru`` team to the bug.
543
736