/breezy/unstable

To get this branch, use:
bzr branch https://code.breezy-vcs.org/breezy/unstable

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Jelmer Vernooij
  • Date: 2017-05-24 01:39:33 UTC
  • mfrom: (3815.3776.6)
  • Revision ID: jelmer@jelmer.uk-20170524013933-ir4y4tqtrsiz2ka2
New upstream snapshot.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
Releasing Bazaar
 
1
Releasing Breezy
2
2
################
3
3
 
4
 
This document describes the processes for making and announcing a Bazaar
 
4
This document describes the processes for making and announcing a Breezy
5
5
release, and managing the release process.  This is just one phase of the
6
6
`overall development cycle
7
7
<http://doc.bazaar.canonical.com/developers/cycle.html>`_, (go re-read this
27
27
 
28
28
#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
29
29
 
30
 
     bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
 
30
     brz branch lp:brz-pqm ~/.bazaar/plugins/pqm
31
31
 
32
32
#. Alternatively, you can download and install ``lp:hydrazine`` (the main
33
33
   difference is that hydrazine requires the branch to land to be hosted on
39
39
In this document, we're talking about source releases only, packages and
40
40
installers are built from this but we won't talk about them here.
41
41
 
42
 
Every release is part of a series, ``bzr-2.4.1`` is part of series ``2.4``.
 
42
Every release is part of a series, ``brz-2.4.1`` is part of series ``2.4``.
43
43
 
44
44
We do two different kind of releases: the betas releases and the stable
45
45
releases for a given series.
46
46
 
47
 
For a given series, releases will be done to deliver new versions of bzr to
 
47
For a given series, releases will be done to deliver new versions of brz to
48
48
different kinds of users:
49
49
 
50
50
#. beta releases: named ``x.ybn`` where ``x.y`` is the series and ``n``
129
129
#. Start a new release-notes file::
130
130
 
131
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
 
132
       cp series-template.txt brz-x.y.txt  # e.g. brz-2.3.txt
 
133
       brz add brz-x.y.txt
134
134
 
135
135
#. Start a new whats-new file::
136
136
 
137
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
 
138
       cp template.txt brz-x.y.txt  # e.g. brz-2.6.txt
 
139
       brz add brz-x.y.txt
140
140
 
141
141
#. Update ``doc/en/index.txt`` to point to the new whats-new file.
142
142
 
153
153
 
154
154
#. Make a local branch to prepare the release::
155
155
 
156
 
        bzr branch lp:bzr/x.y x.y-dev
 
156
        brz branch lp:brz/x.y x.y-dev
157
157
 
158
158
   If you're doing your first beta release, branch from trunk::
159
159
 
160
 
       bzr branch lp:bzr x.y-dev
 
160
       brz branch lp:brz x.y-dev
161
161
 
162
162
   Note that you will generally reuse the same branch for all releases in a
163
163
   given series.
166
166
   ``x.y`` is the series for your release). **Or use hydrazine for easier
167
167
   setup** ``~/.bazaar/locations.conf``::
168
168
 
169
 
        [/home/mbp/bzr/x.y-dev]
 
169
        [/home/mbp/brz/x.y-dev]
170
170
        pqm_email = Canonical PQM <pqm@bazaar-vcs.org>
171
 
        submit_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
172
 
        parent_branch = http://bazaar.launchpad.net/~bzr-pqm/bzr/x.y
 
171
        submit_branch = http://bazaar.launchpad.net/~brz-pqm/brz/x.y
 
172
        parent_branch = http://bazaar.launchpad.net/~brz-pqm/brz/x.y
173
173
        public_branch = http://bazaar.example.com/x.y-dev
174
174
        submit_to = bazaar@lists.canonical.com
175
175
        smtp_server = mail.example.com:25
177
177
    Please see <http://doc.bazaar.canonical.com/developers/HACKING.html#an-overview-of-pqm>
178
178
    for more details on PQM
179
179
 
180
 
#. Update the version number in the ``bzr`` script, and the
181
 
   ``bzrlib/__init__.py`` file::
 
180
#. Update the version number in the ``brz`` script, and the
 
181
   ``breezy/__init__.py`` file::
182
182
   
183
183
       version_info = (x, y, z, 'dev', 0)
184
184
   
211
211
   merged yet. For example, if you're releasing 2.6.x, make sure the fixes
212
212
   on 2.5, 2.4, 2.3, etc have already been merged up::
213
213
 
214
 
     bzr merge lp:bzr/2.4
 
214
     brz merge lp:brz/2.4
215
215
 
216
216
   and commit that merge in its own commit. This should happen only if the
217
217
   devs landing changes in previous releases forgot to merge them up. Since
219
219
   their duties ;) If you feel unsafe resolving the conflicts or it's too
220
220
   time consuming, contact the related devs and skip this merge.
221
221
 
222
 
#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``.
 
222
#. In the release branch, update  ``version_info`` in ``./breezy/__init__.py``.
223
223
   Make sure the corresponding milestone exists.
224
 
   Double check that ./bzr ``_script_version`` matches ``version_info``. Check
225
 
   the output of ``./bzr --version``.
 
224
   Double check that ./brz ``_script_version`` matches ``version_info``. Check
 
225
   the output of ``./brz --version``.
226
226
 
227
227
   For beta releases use::
228
228
 
242
242
   the right section. For example, if you're releasing 2.6b2, the following
243
243
   command should display a a single chuk diff for the 2.6b2 release::
244
244
 
245
 
     bzr diff -rbzr-2.6b2.. doc/en/release-notes/bzr-2.6.txt
 
245
     brz diff -rbrz-2.6b2.. doc/en/release-notes/brz-2.6.txt
246
246
 
247
247
   Fill out the date and a description of the release under the existing
248
248
   header (the diff above will help you summarizing). If there isn't one,
259
259
  * the date of this first release,
260
260
  * until when the series is expected to be supported.
261
261
 
262
 
  Looking at ``bzr annotate`` for previous series should give you the right
 
262
  Looking at ``brz annotate`` for previous series should give you the right
263
263
  hints. The ``doc/en/_templates/index.html`` file should also be updated.
264
264
 
265
265
#. To check that all bugs mentioned in the release notes are actually
266
266
   marked as closed in Launchpad, you can run
267
267
   ``tools/check-newsbugs.py``::
268
268
 
269
 
     ./tools/check-newsbugs.py doc/en/release-notes/bzr-x.y.txt
 
269
     ./tools/check-newsbugs.py doc/en/release-notes/brz-x.y.txt
270
270
 
271
271
   As of 2011-07-18, all bugs mentioned in the output of the script requires
272
272
   some sort of intervention (either changing the status if it's not 'Fix
278
278
 
279
279
#. For beta releases update the translation template::
280
280
 
281
 
     BZR_PLUGIN_PATH=-site make po/bzr.pot
 
281
     BRZ_PLUGIN_PATH=-site make po/brz.pot
282
282
 
283
283
   This is especially important for the final beta release which is when
284
284
   translations are frozen and translators are requested (see `The final
286
286
 
287
287
#. For stable releases update the translations::
288
288
 
289
 
     bzr merge lp:~bzr-core/bzr/bzr-translations-export-x.y
 
289
     brz merge lp:~brz-core/brz/brz-translations-export-x.y
290
290
 
291
291
#. Commit these changes to the release branch, using a command like::
292
292
 
293
 
     bzr commit -m "Release 2.3.1"
 
293
     brz commit -m "Release 2.3.1"
294
294
 
295
295
   The diff before you commit will be something like::
296
296
 
297
 
      === modified file 'bzrlib/__init__.py'
298
 
      --- bzrlib/__init__.py    2011-02-09 06:35:00 +0000
299
 
      +++ bzrlib/__init__.py    2011-03-10 10:24:47 +0000
 
297
      === modified file 'breezy/__init__.py'
 
298
      --- breezy/__init__.py    2011-02-09 06:35:00 +0000
 
299
      +++ breezy/__init__.py    2011-03-10 10:24:47 +0000
300
300
      @@ -52,7 +52,7 @@
301
301
       # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
302
302
       # releaselevel of 'dev' for unreleased under-development code.
307
307
       # API compatibility version
308
308
       api_minimum_version = (2, 3, 0)
309
309
      
310
 
      === modified file 'doc/en/release-notes/bzr-2.3.txt'
311
 
      --- doc/en/release-notes/bzr-2.3.txt      2011-03-09 08:30:16 +0000
312
 
      +++ doc/en/release-notes/bzr-2.3.txt      2011-03-10 10:40:47 +0000
 
310
      === modified file 'doc/en/release-notes/brz-2.3.txt'
 
311
      --- doc/en/release-notes/brz-2.3.txt      2011-03-09 08:30:16 +0000
 
312
      +++ doc/en/release-notes/brz-2.3.txt      2011-03-10 10:40:47 +0000
313
313
      @@ -8,23 +8,10 @@
314
 
       bzr 2.3.1
 
314
       brz 2.3.1
315
315
       #########
316
316
       
317
317
      -:2.3.1: NOT RELEASED YET
319
319
      -External Compatibility Breaks
320
320
      -*****************************
321
321
      -
322
 
      -.. These may require users to change the way they use Bazaar.
 
322
      -.. These may require users to change the way they use Breezy.
323
323
      -
324
324
      -New Features
325
325
      -************
344
344
      +++ doc/en/whats-new/whats-new-in-2.3.txt 2011-03-10 11:10:36 +0000
345
345
      @@ -17,8 +17,13 @@
346
346
       improvements made to the core product, it highlights enhancements within the
347
 
       broader Bazaar world of potential interest to those upgrading.
 
347
       broader Breezy world of potential interest to those upgrading.
348
348
       
349
 
      -Bazaar 2.3.0 is fully compatible both locally and on the network with 2.0 2.1,
 
349
      -Breezy 2.3.0 is fully compatible both locally and on the network with 2.0 2.1,
350
350
      -and 2.2, and can read and write repositories generated by all previous
351
 
      +Bazaar 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5
 
351
      +Breezy 2.3.1 includes all the fixes in the un-released 2.0.7, 2.1.4 and 2.2.5
352
352
      +versions that weren't included in 2.3.0 and fixes some bugs on its own.
353
353
      +
354
354
      +See the :doc:`../release-notes/index` for details.
355
355
      +
356
 
      +Bazaar 2.3 is fully compatible both locally and on the network with 2.0, 2.1,
 
356
      +Breezy 2.3 is fully compatible both locally and on the network with 2.0, 2.1,
357
357
      +and 2.2. It can read and write repositories generated by all previous
358
358
       versions.
359
359
       
362
362
 
363
363
#. Tag the new release::
364
364
 
365
 
     bzr tag bzr-2.6.0
 
365
     brz tag brz-2.6.0
366
366
 
367
 
#. Push those changes to a bzr branch that is public and accessible on the
 
367
#. Push those changes to a brz branch that is public and accessible on the
368
368
   Internet. PQM will pull from this branch when it attempts to merge your
369
369
   changes. Then submit those changes to PQM for merge into the appropriate
370
370
   release branch::
371
371
 
372
 
     bzr push
373
 
     bzr pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
 
372
     brz push
 
373
     brz pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
374
374
 
375
 
   Note that ``bzr push`` should mention updating one tag (which you just
 
375
   Note that ``brz push`` should mention updating one tag (which you just
376
376
   created). If it doesn't, double-check that you created (and pushed) this
377
377
   tag.
378
378
 
379
379
   Or with hydrazine::
380
380
 
381
 
     bzr lp-propose -m "Release 1.14" --approve lp:bzr/1.14
382
 
     feed-pqm bzr
 
381
     brz lp-propose -m "Release 1.14" --approve lp:brz/1.14
 
382
     feed-pqm brz
383
383
 
384
384
#. When PQM succeeds, pull down the master release branch.
385
385
 
400
400
   locally installed plugins. Use your own judgment to decide if you can
401
401
   release with these failures. When in doubt, disable the faulty plugins
402
402
   one by one until you get no more failures. Alternatively, you can use
403
 
   ``BZR_DISABLE_PLUGINS`` or ``BZR_PLUGIN_PATH=-site`` to disable one or
 
403
   ``BRZ_DISABLE_PLUGINS`` or ``BRZ_PLUGIN_PATH=-site`` to disable one or
404
404
   all plugins.
405
405
 
406
406
   Until <http://pad.lv/839461> is fixed, you may encounter issues if you
410
410
 
411
411
     export TTPATH=<local branch of lp:testtools -r 0.9.2>
412
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
 
413
     PYTHONPATH=$TTPATH:$SUPATH/python PATH=$SUPATH/filters:${PATH} BRZ_PLUGIN_PATH=-site make check-dist-tarball PYTHON=python2.6 | subunit2pyunit
414
414
 
415
415
   Remember that PQM has just tested everything too, this step is
416
416
   particularly testing that the pyrex extensions, which are updated
426
426
#. Create a release of the milestone, and upload the source tarball and
427
427
   the GPG signature.  Or, if you prefer, use the
428
428
   ``tools/packaging/lp-upload-release`` script to do this. Note that
429
 
   this changes what the download widget on the Launchpad bzr home
 
429
   this changes what the download widget on the Launchpad brz home
430
430
   page shows, so don't stop the release process yet, or platform binary
431
431
   installers won't be made and the download list will stay very small!
432
432
   <https://bugs.launchpad.net/launchpad/+bug/586445>
443
443
they do, they either targeted the wrong branch or didn't update the news
444
444
file correctly, so the sooner the branch is opened again, the better.
445
445
 
446
 
This matters more for ``lp:bzr`` than for ``lp:bzr/x.y``, ``lp:bzr`` should
 
446
This matters more for ``lp:brz`` than for ``lp:brz/x.y``, ``lp:brz`` should
447
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
 
448
cycle`_ as soon as possible (i.e. update the version number in ``brz`` and
 
449
``breezy/__init__``, create/update the news files and create/update the
450
450
milestone for the next relase).
451
451
 
452
452
You may also need to do `At the start of a series cycle`_ if you're starting
457
457
 
458
458
A word of caution: the instructions above works well for all releases but
459
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
 
460
the *last* beta for a given ``x.y`` series (from trunk aka lp:brz), you need
461
461
to setup *two* branches for the next cycle:
462
462
 
463
 
#. ``lp:bzr`` needs to be opened for the next *series* ``x.(y+1)``.
 
463
#. ``lp:brz`` needs to be opened for the next *series* ``x.(y+1)``.
464
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
 
465
#. ``lp:brz/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:brz/x.y``, this is also the
467
467
   deadline for the PQM branch to be created.
468
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
 
469
Both are important as ``lp:brz`` should remain open so any change can be
 
470
landed, ``lp:brz/x.y`` on the other hand should be ready to receive bug
471
471
fixes.
472
472
 
473
 
``lp:bzr`` is generally more important as the bug fixes on ``lp:bzr/x.y``
 
473
``lp:brz`` is generally more important as the bug fixes on ``lp:brz/x.y``
474
474
won't be released sooner than a month from now whereas people may already
475
 
been waiting to land on ``lp:bzr``.
 
475
been waiting to land on ``lp:brz``.
476
476
 
477
477
In a nutshell:
478
478
 
479
 
#. Open ``lp:bzr`` for ``x.(y+1)``
 
479
#. Open ``lp:brz`` for ``x.(y+1)``
480
480
 
481
481
#. Create or update the ``x.y`` PQM branch based on whatever revision you
482
482
   want to release. Since it takes time to create the PQM branch for the new
483
483
   series you should plan to get it created a few days before you need it
484
484
   and seed it with the revision from trunk you want to base your release of
485
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
 
486
   series branch (``lp:brz/x.y``) when you're ready).
 
487
 
 
488
#. Release ``x.y.0`` from ``lp:brz/x.y``
 
489
 
 
490
#. Open ``lp:brz/x.y`` for bug fixes
491
491
 
492
492
You also need to ensure Launchpad is set up to import/export translations
493
493
for the new branch and inform translators.
494
494
 
495
495
#. Push the last beta release to a new branch::
496
496
 
497
 
     bzr push lp:~bzr-core/bzr/bzr-translations-export-x.y
 
497
     brz push lp:~brz-core/brz/brz-translations-export-x.y
498
498
 
499
499
#. On the translations series synchronization settings page
500
500
   <https://translations.launchpad.net/bzr/x.y/+translations-settings>
501
501
   turn on ``Import template files`` then for exports click ``Choose a
502
502
   target branch`` and point it at the branch you just pushed.
503
503
 
504
 
#. E-mail translators to announce that the forthcoming stable release of bzr
 
504
#. E-mail translators to announce that the forthcoming stable release of brz
505
505
   is ready for translations.  Send to
506
506
   ``launchpad-translators@lists.launchpad.net`` and
507
507
   ``ubuntu-translators@lists.ubuntu.com``.
513
513
----------------------------
514
514
 
515
515
#. Post to the ``bazaar@lists.canonical.com`` and
516
 
   ``bzr-packagers@list.launchpad.net`` lists, saying that the source has
 
516
   ``brz-packagers@lists.launchpad.net`` lists, saying that the source has
517
517
   been frozen. Be extra clear that this is only a *source* release targeted
518
518
   at packagers and installer builders (see
519
519
   <https://bugs.launchpad.net/launchpad/+bug/645084>).  This is the cue for
543
543
 
544
544
#. Go to the release web page at <https://launchpad.net/bzr/x.y/x.y.z>
545
545
 
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
548
 
   pushed to this branch are refreshed by a cron job on escudero.)
 
546
#. Announce on the Breezy website.
549
547
 
550
548
#. Check that the documentation for this release is available in
551
549
   <http://doc.bazaar.canonical.com>.  It should be automatically build when
552
 
   the branch is created, by a cron script ``update-bzr-docs`` on
 
550
   the branch is created, by a cron script ``update-brz-docs`` on
553
551
   ``escudero``. When the first release is created in a new series, a branch
554
 
   needs to be created on zhongshan::
 
552
   needs to be created on ``escudero``::
555
553
 
556
 
     ssh zhongshan.canonical.com
557
 
     sudo -u bzr-web -s
 
554
     ssh escudero.canonical.com
 
555
     sudo -u brz-web -s
558
556
     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
 
557
     brz branch lp:brz/2.7 brz/brz.2.7
 
558
 
 
559
   And the ``brz/bin/update-brz-docs`` script needs to refer to it.
 
560
 
 
561
   The ``lp:brz-alldocs`` branch also needs to be updated when a new series
564
562
   is introduced, see the ``README`` file there for more instructions
565
563
   (looking at the branch history is also a good way to understand what
566
564
   needs to be done and to document any policy changes).
584
582
 
585
583
   The announce mail will look something like this::
586
584
 
587
 
      Subject: bzr x.y.z released!
588
 
 
589
 
      The Bazaar team is happy to announce availability of a new
590
 
      release of the bzr adaptive version control system.
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.
 
585
      Subject: brz x.y.z released!
 
586
 
 
587
      The Breezy team is happy to announce availability of a new
 
588
      release of the brz adaptive version control system.
 
589
 
 
590
      Breezy is a fork of the Bazaar version control system.
595
591
 
596
592
      <<Summary paragraph from news>>
597
593
 
598
594
      Thanks to everyone who contributed patches, suggestions, and
599
595
      feedback.
600
596
 
601
 
      Bazaar is now available for download from
 
597
      Breezy is now available for download from
602
598
      https://launchpad.net/bzr/x.y/x.y.z/ as a source tarball; packages
603
599
      for various systems will be available soon.
604
600
 
632
628
     the ``Links`` box in the upper right area of the page. When doing the
633
629
     first stable release in a series, delete the ``Unstable installers``
634
630
     <https://launchpad.net/bzr/x.y/x.ybn> and ``Unstable source tarball``
635
 
     <http://launchpad.net/bzr/x.y/x.ybn/+download/bzr-x.ybn.tar.gz>
 
631
     <http://launchpad.net/bzr/x.y/x.ybn/+download/brz-x.ybn.tar.gz>
636
632
     links. Conversely, when creating the first beta in a development
637
633
     series, create these links again. Check all links when doing other
638
634
     kinds of release.
639
635
 
640
 
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
 
636
#. Update `<http://en.wikipedia.org/wiki/Breezy_(software)>`_ -- this should
641
637
   be done for the stable and beta releases.
642
638
 
643
 
#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
644
 
   done by running ::
645
 
 
646
 
       python setup.py register
 
639
#. Update the python package index: <http://pypi.python.org/pypi/brz>
 
640
 
 
641
   From the tarball created and tested earlier ::
 
642
 
 
643
     twine upload -s ../brz-2.7.0.tar.gz
647
644
 
648
645
   Remember to check the results afterward -- this should be done for
649
646
   stable releases but not for beta releases nor SRUs.
650
647
 
651
 
   To be able to register the release you must create an account on
652
 
   <http://pypi.python.org/pypi> and have one of the existing owners of
653
 
   the project add you to the group.
 
648
   The ``twine`` command is provided by the ``twine`` package on Debian and
 
649
   Ubuntu.
 
650
 
 
651
   If in doubt, you can test with <https://testpypi.python.org/pypi> where
 
652
   you can register yourself, register the brz project and upload (and then
 
653
   remove the upload and delete the project so a new release manager can
 
654
   enjoy the same facilities). If the project already exists, have one of
 
655
   the existing owners of the project add you to the group.
 
656
 
 
657
   To use the pypi test site, you need to record your credentials for an
 
658
   existing user (the registration process is manual and starts at
 
659
   <https://testpypi.python.org/pypi?%3Aaction=register_form>.
 
660
 
 
661
   Once registered, you can record your crdentials in your ``~/pypirc`` file
 
662
   with ::
 
663
 
 
664
     [testpypi]
 
665
     username:<login on testpypi>
 
666
     password:<password on testpypi>
 
667
     repository = https://testpypi.python.org/pypi
 
668
 
 
669
   Registering the brz project if doesn't exist is achieved with::
 
670
 
 
671
     python setup.py -r https://testpypi.python.org/pypi register
 
672
 
 
673
  Uploading is done with::
 
674
 
 
675
    twine upload -r testpypi -s ../brz-2.7.0.tar.gz
 
676
 
 
677
   To be able to upload the release you must create an account on
 
678
   <http://pypi.python.org/pypi> and have one of the existing owners of the
 
679
   project add you to the group and update your ``[pypi]`` section in your
 
680
   ``~/pypirc`` file.
654
681
 
655
682
 
656
683
Merging the released code back to trunk
660
687
changes should be merged into the right place because each release series
661
688
has its own release-notes file, but double-check.
662
689
 
663
 
If it's not already done, advance the version number in ``bzr`` and
664
 
``bzrlib/__init__.py``.  Submit this back into pqm for bzr.dev.
 
690
If it's not already done, advance the version number in ``brz`` and
 
691
``breezy/__init__.py``.  Submit this back into pqm for brz.dev.
665
692
 
666
693
As soon as you change the version number in trunk, make sure you have
667
694
created the corresponding milestone to ensure the continuity in bug
688
715
-------------------------------
689
716
 
690
717
(Feel free to propose or add new sections here about what we should do to
691
 
get bzr into other places.)
 
718
get brz into other places.)
692
719
 
693
720
For the currently-under-development release of Ubuntu, no special action
694
721
is needed: the release should be picked by Debian and synced from there into
695
722
Ubuntu.
696
723
 
697
 
Releases off stable bzr branches should go in to the ``-updates`` of the
 
724
Releases off stable brz branches should go in to the ``-updates`` of the
698
725
Ubuntu release that originally contained that branch.  (Ubuntu Lucid had
699
 
bzr 2.2.0, so should get every 2.2.x update.)  This means going through
 
726
brz 2.2.0, so should get every 2.2.x update.)  This means going through
700
727
the `SRU (Stable Release Updates)
701
728
<https://wiki.ubuntu.com/StableReleaseUpdates>`__ process.   
702
729
 
703
 
Since September 2010, bzr has received approval by the technical
 
730
Since September 2010, brz has received approval by the technical
704
731
board for the `MicroReleaseExceptions
705
732
<https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions>`__
706
733
category so that whole bugfix releases can more easily be
710
737
<http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates>`_
711
738
page.
712
739
 
713
 
**After making a bzr stable-release release, nominate the most serious bug
 
740
**After making a brz stable-release release, nominate the most serious bug
714
741
for the appropriate Ubuntu release and subscribe the `ubuntu-sru` team.**
715
742
 
716
743
This requires a couple of tricks (please reconsider and tweak as things
717
744
evolves from one release to the other):
718
745
 
719
746
 * create a distro task with the ``Also affects distribution`` button and
720
 
   select ``bzr (Ubuntu)``.
 
747
   select ``brz (Ubuntu)``.
721
748
 
722
 
 * change the *URL* to point to ``ubuntu/+source/bzr`` instead of ``bzr``
 
749
 * change the *URL* to point to ``ubuntu/+source/brz`` instead of ``brz``
723
750
   (this is needed if you create the distro task but not if it exists
724
751
   already). You should now be able to click the ``Nominate for release``
725
752
   button and select the right Ubuntu release. As of September 2010, this
744
771
See also
745
772
--------
746
773
 
747
 
* `Packaging into the bzr PPA <ppa.html>`_ to make and publish Ubuntu
 
774
* `Packaging into the brz PPA <ppa.html>`_ to make and publish Ubuntu
748
775
  packages.
749
 
* `Bazaar Developer Document Catalog <index.html>`_
 
776
* `Breezy Developer Document Catalog <index.html>`_
750
777
* `Development cycles <cycle.html>`_: things that happen during the cycle
751
778
  before the actual release.
752
779