206
207
also mail the list to raise this issue in our process. Milestones are
207
208
found at <https://launchpad.net/bzr/+milestone/x.y.z>.
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::
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.
209
222
#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``.
210
223
Make sure the corresponding milestone exists.
211
224
Double check that ./bzr ``_script_version`` matches ``version_info``. Check
214
227
For beta releases use::
216
version_info = (2, 1, 0, 'beta', SERIAL)
220
version_info = (2, 1, 0, 'beta', 1)
229
version_info = (2, 6, 0, 'beta', SERIAL)
233
version_info = (2, 6, 0, 'beta', 1)
222
235
For stable releases use::
224
version_info = (2, 1, 2, 'final', 0)
237
version_info = (2, 6, 0, 'final', 0)
226
239
#. Update the ``./doc/en/release-notes/`` section for this release.
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::
245
bzr diff -rbzr-2.6b2.. doc/en/release-notes/bzr-2.6.txt
228
247
Fill out the date and a description of the release under the existing
229
header. If there isn't one, follow the instructions above for using the
230
``release-template.txt`` file.
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 ;)
232
See *2.1.1* or similar for an example of what this looks like.
252
See *2.6b1* or similar for an example of what this looks like.
234
254
#. 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.
236
265
#. To check that all bugs mentioned in the release notes are actually
237
266
marked as closed in Launchpad, you can run
238
267
``tools/check-newsbugs.py``::
250
279
#. For beta releases update the translation template::
281
BZR_PLUGIN_PATH=-site make po/bzr.pot
254
This is especially important for the final beta release which is
255
when translations are frozen and translators are requested to make
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.
258
287
#. For stable releases update the translations::
427
460
the *last* beta for a given ``x.y`` series (from trunk aka lp:bzr), you need
428
461
to setup *two* branches for the next cycle:
430
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``
463
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``.
432
465
#. ``lp:bzr/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
433
466
series. Since this is first real use of ``lp:bzr/x.y``, this is also the
446
#. Create or update the ``x.y`` PQM branch based on whatever
447
revision you want to release
449
479
#. 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).
451
488
#. Release ``x.y.0`` from ``lp:bzr/x.y``
453
490
#. Open ``lp:bzr/x.y`` for bug fixes
455
You also need to ensure Launchpad is set up to import/export
456
translations for the new branch and inform translators.
492
You also need to ensure Launchpad is set up to import/export translations
493
for the new branch and inform translators.
495
#. Push the last beta release to a new branch::
460
497
bzr push lp:~bzr-core/bzr/bzr-translations-export-x.y
464
501
turn on ``Import template files`` then for exports click ``Choose a
465
502
target branch`` and point it at the branch you just pushed.
467
#. E-mail translators to announce that the forthcoming stable release
468
of bzr is ready for translations. Send to
469
``translators@lists.launchpad.net`` and
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
470
507
``ubuntu-translators@lists.ubuntu.com``.
472
509
#. The series is now frozen for strings and API, see below for adding
475
512
Announcing the source freeze
476
513
----------------------------
478
#. Post to the ``bazaar@lists.canonical.com`` list, saying that the source
479
has been frozen (gone gold). Be extra clear that this is only a *source*
480
release targeted at packagers and installer builders (see
515
#. Post to the ``bazaar@lists.canonical.com`` and
516
``bzr-packagers@lists.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
481
519
<https://bugs.launchpad.net/launchpad/+bug/645084>). This is the cue for
482
520
platform maintainers and plugin authors to update their code. This is
483
521
done before the general public announcement of the release.
489
527
control the process as tightly so guessing the date is not appropriate.
491
529
For the final beta release include in your announcement a notice of
492
API and translation freezes nothing that public methods should not
530
API and translation freezes noting that public methods should not
493
531
be removed or changed and strings should not be added or changed.
495
533
#. Pause for a few days.
499
537
----------------------
501
539
There is normally a delay of a few days after the source freeze to allow
502
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,
503
541
we have a releasable product. The next step is to make it generally
504
542
available to the world.
506
544
#. Go to the release web page at <https://launchpad.net/bzr/x.y/x.y.z>
508
#. Announce on the `Bazaar website <http://bazaar.canonical.com/>`_.
509
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
510
548
pushed to this branch are refreshed by a cron job on escudero.)
512
550
#. Check that the documentation for this release is available in
513
<http://doc.bazaar.canonical.com>. It should be automatically build when the
514
branch is created, by a cron script ``update-bzr-docs`` on
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 lp:bzr/2.7 bzr/bzr.2.7
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).
518
568
Announcing the release
519
569
----------------------
557
607
Feel free to tweak this to your taste.
559
609
#. Make an announcement through <https://launchpad.net/bzr/+announce>
610
mentioning the milestone URL <https://launchpad.net/bzr/+milestone/x.y.z>
611
so people get an easy access to details.
561
#. Announce on http://freshmeat.net/projects/bzr/
613
#. Announce on https://freecode.com/projects/bazaar-vcs
563
615
This should be done for beta releases and stable releases. If you do not
564
have a Freshmeat account yet, ask one of the existing admins.
616
have a Freecode account yet, ask one of the existing admins.
566
618
The purpose here is to point users to the latest stable release
567
619
(i.e. SRUs are excluded) while still publishing announcements for beta
585
637
series, create these links again. Check all links when doing other
586
638
kinds of release.
588
* Set direct download: When releasing a new stable release, this should
589
point to the corresponding launchpad page:
590
<https://launchpad.net/bzr/x.y/x.y.z/>
592
640
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
593
641
be done for the stable and beta releases.
595
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
598
python setup.py register
643
#. Update the python package index: <http://pypi.python.org/pypi/bzr>
645
From the tarball created and tested earlier ::
647
twine upload -s ../bzr-2.7.0.tar.gz
600
649
Remember to check the results afterward -- this should be done for
601
650
stable releases but not for beta releases nor SRUs.
603
To be able to register the release you must create an account on
604
<http://pypi.python.org/pypi> and have one of the existing owners of
605
the project add you to the group.
652
The ``twine`` command is provided by the ``twine`` package on Debian and
655
If in doubt, you can test with <https://testpypi.python.org/pypi> where
656
you can register yourself, register the bzr project and upload (and then
657
remove the upload and delete the project so a new release manager can
658
enjoy the same facilities). If the project already exists, have one of
659
the existing owners of the project add you to the group.
661
To use the pypi test site, you need to record your credentials for an
662
existing user (the registration process is manual and starts at
663
<https://testpypi.python.org/pypi?%3Aaction=register_form>.
665
Once registered, you can record your crdentials in your ``~/pypirc`` file
669
username:<login on testpypi>
670
password:<password on testpypi>
671
repository = https://testpypi.python.org/pypi
673
Registering the bzr project if doesn't exist is achieved with::
675
python setup.py -r https://testpypi.python.org/pypi register
677
Uploading is done with::
679
twine upload -r testpypi -s ../bzr-2.7.0.tar.gz
681
To be able to upload the release you must create an account on
682
<http://pypi.python.org/pypi> and have one of the existing owners of the
683
project add you to the group and update your ``[pypi]`` section in your
608
687
Merging the released code back to trunk
677
756
button and select the right Ubuntu release. As of September 2010, this
759
* ``quantal`` for the 2.6 series,
760
* ``precise`` for the 2.5 series,
680
761
* ``oneiric`` for the 2.4 series,
681
762
* ``natty`` for the 2.3 series,
682
763
* ``maverick`` for the 2.2 series,
added
removed
doc/developers/releasing.txt
