208
207
found at <https://launchpad.net/bzr/+milestone/x.y.z>.
210
209
#. 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::
210
merged yet. For example, if you're releasing 2.5.x, make sure the fixes
211
on 2.4, 2.3, etc have already been merged up::
214
213
bzr merge lp:bzr/2.4
227
226
For beta releases use::
229
version_info = (2, 6, 0, 'beta', SERIAL)
233
version_info = (2, 6, 0, 'beta', 1)
228
version_info = (2, 1, 0, 'beta', SERIAL)
232
version_info = (2, 1, 0, 'beta', 1)
235
234
For stable releases use::
237
version_info = (2, 6, 0, 'final', 0)
236
version_info = (2, 1, 2, 'final', 0)
239
238
#. Update the ``./doc/en/release-notes/`` section for this release.
241
240
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::
241
the right section. For example, if you're releasing 2.5b2, the following
242
command should display a a single chuk diff for the 2.5b2 release::
245
bzr diff -rbzr-2.6b2.. doc/en/release-notes/bzr-2.6.txt
244
bzr diff -rbzr-2.5b1.. doc/en/release-notes/bzr-2.5.txt
247
246
Fill out the date and a description of the release under the existing
248
247
header (the diff above will help you summarizing). If there isn't one,
249
248
follow the instructions above for using the ``release-template.txt`` file
250
249
and remind people that they should document their changes there ;)
252
See *2.6b1* or similar for an example of what this looks like.
251
See *2.1.1* or similar for an example of what this looks like.
254
253
#. Add or check the summary of the release into the "What's New" document.
256
If this is the first release in a new series make sure to update the
257
introduction mentioning:
259
* the date of this first release,
260
* until when the series is expected to be supported.
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.
265
255
#. To check that all bugs mentioned in the release notes are actually
266
256
marked as closed in Launchpad, you can run
267
257
``tools/check-newsbugs.py``::
281
271
BZR_PLUGIN_PATH=-site make po/bzr.pot
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.
273
This is especially important for the final beta release which is
274
when translations are frozen and translators are requested to make
287
277
#. For stable releases update the translations::
460
450
the *last* beta for a given ``x.y`` series (from trunk aka lp:bzr), you need
461
451
to setup *two* branches for the next cycle:
463
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``.
453
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``
465
455
#. ``lp:bzr/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
466
456
series. Since this is first real use of ``lp:bzr/x.y``, this is also the
469
#. Create or update the ``x.y`` PQM branch based on whatever
470
revision you want to release
479
472
#. Open ``lp:bzr`` for ``x.(y+1)``
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).
488
474
#. Release ``x.y.0`` from ``lp:bzr/x.y``
490
476
#. Open ``lp:bzr/x.y`` for bug fixes
492
You also need to ensure Launchpad is set up to import/export translations
493
for the new branch and inform translators.
478
You also need to ensure Launchpad is set up to import/export
479
translations for the new branch and inform translators.
495
#. Push the last beta release to a new branch::
497
483
bzr push lp:~bzr-core/bzr/bzr-translations-export-x.y
548
534
pushed to this branch are refreshed by a cron job on escudero.)
550
536
#. Check that the documentation for this release is available in
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 escudero::
556
ssh escudero.canonical.com
558
cd /srv/doc.bazaar.canonical.com/
559
bzr branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.5 bzr.2.5
561
And the ``bzr/bin/update-bzr-docs`` script needs to refer to it.
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).
537
<http://doc.bazaar.canonical.com>. It should be automatically build when the
538
branch is created, by a cron script ``update-bzr-docs`` on
568
542
Announcing the release
569
543
----------------------
637
609
series, create these links again. Check all links when doing other
638
610
kinds of release.
612
* Set direct download: When releasing a new stable release, this should
613
point to the corresponding launchpad page:
614
<https://launchpad.net/bzr/x.y/x.y.z/>
640
616
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
641
617
be done for the stable and beta releases.
725
701
button and select the right Ubuntu release. As of September 2010, this
728
* ``quantal`` for the 2.6 series,
729
* ``precise`` for the 2.5 series,
730
704
* ``oneiric`` for the 2.4 series,
731
705
* ``natty`` for the 2.3 series,
732
706
* ``maverick`` for the 2.2 series,
added
removed
doc/developers/releasing.txt
