← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Patch Queue Manager
  • Date: 2012-03-12 08:40:59 UTC
  • mfrom: (6474.2.6 work)
  • Revision ID: pqm@pqm.ubuntu.com-20120312084059-564pa15g5dgnggts
(vila) More releasing instructions updates from 2.5.0 release. (Vincent
 Ladeuil)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
138
138
       cp template.txt bzr-x.y.txt  # e.g. bzr-2.6.txt
139
139
       bzr add bzr-x.y.txt
140
140
 
 
141
#. Update ``doc/en/index.txt`` to point to the new whats-new file.
141
142
 
142
143
At the start of a release cycle
143
144
===============================
207
208
   found at <https://launchpad.net/bzr/+milestone/x.y.z>.
208
209
 
209
210
#. Merge into your branch all previous stable series fixes that haven't been
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::
 
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::
212
213
 
213
214
     bzr merge lp:bzr/2.4
214
215
 
225
226
 
226
227
   For beta releases use::
227
228
 
228
 
       version_info = (2, 5, 0, 'beta', SERIAL)
229
 
 
230
 
   For instance 2.5b5::
231
 
 
232
 
       version_info = (2, 5, 0, 'beta', 5)
 
229
       version_info = (2, 6, 0, 'beta', SERIAL)
 
230
 
 
231
   For instance 2.6b1::
 
232
 
 
233
       version_info = (2, 6, 0, 'beta', 1)
233
234
 
234
235
   For stable releases use::
235
236
 
236
 
       version_info = (2, 5, 0, 'final', 0)
 
237
       version_info = (2, 6, 0, 'final', 0)
237
238
 
238
239
#. Update the ``./doc/en/release-notes/`` section for this release.
239
240
 
240
241
   Check that all news entries related to this release have been added in
241
 
   the right section. For example, if you're releasing 2.5b5, the following
242
 
   command should display a a single chuk diff for the 2.5b5 release::
 
242
   the right section. For example, if you're releasing 2.6b1, the following
 
243
   command should display a a single chuk diff for the 2.6b1 release::
243
244
 
244
 
     bzr diff -rbzr-2.5b4.. doc/en/release-notes/bzr-2.5.txt
 
245
     bzr diff -rbzr-2.6b1.. doc/en/release-notes/bzr-2.6.txt
245
246
 
246
247
   Fill out the date and a description of the release under the existing
247
248
   header (the diff above will help you summarizing). If there isn't one,
248
249
   follow the instructions above for using the ``release-template.txt`` file
249
250
   and remind people that they should document their changes there ;)
250
251
 
251
 
   See *2.5b5* or similar for an example of what this looks like.
 
252
   See *2.6b1* or similar for an example of what this looks like.
252
253
 
253
254
#. Add or check the summary of the release into the "What's New" document.
254
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.
 
264
 
255
265
#. To check that all bugs mentioned in the release notes are actually
256
266
   marked as closed in Launchpad, you can run
257
267
   ``tools/check-newsbugs.py``::
352
362
 
353
363
#. Tag the new release::
354
364
 
355
 
     bzr tag bzr-2.3.1
 
365
     bzr tag bzr-2.6.0
356
366
 
357
367
#. Push those changes to a bzr branch that is public and accessible on the
358
368
   Internet. PQM will pull from this branch when it attempts to merge your
360
370
   release branch::
361
371
 
362
372
     bzr push
363
 
     bzr pqm-submit -m "(vila) Release 2.3.1 (Vincent Ladeuil)"
 
373
     bzr pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
364
374
 
365
375
   Note that ``bzr push`` should mention updating one tag (which you just
366
376
   created). If it doesn't, double-check that you created (and pushed) this
517
527
   control the process as tightly so guessing the date is not appropriate.
518
528
 
519
529
   For the final beta release include in your announcement a notice of
520
 
   API and translation freezes nothing that public methods should not
 
530
   API and translation freezes noting that public methods should not
521
531
   be removed or changed and strings should not be added or changed.
522
532
 
523
533
#. Pause for a few days. 
527
537
----------------------
528
538
 
529
539
There is normally a delay of a few days after the source freeze to allow
530
 
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,
531
541
we have a releasable product.  The next step is to make it generally
532
542
available to the world.
533
543
 
538
548
   pushed to this branch are refreshed by a cron job on escudero.)
539
549
 
540
550
#. Check that the documentation for this release is available in
541
 
   <http://doc.bazaar.canonical.com>.  It should be automatically build when the
542
 
   branch is created, by a cron script ``update-bzr-docs`` on
543
 
   ``escudero``.
544
 
 
 
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::
 
555
 
 
556
     ssh escudero.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.5 bzr.2.5
 
560
 
 
561
   And the ``update-bzr-docs`` 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).
545
567
 
546
568
Announcing the release
547
569
----------------------
615
637
     series, create these links again. Check all links when doing other
616
638
     kinds of release.
617
639
 
618
 
   * Set direct download: When releasing a new stable release, this should
619
 
     point to the corresponding launchpad page:
620
 
     <https://launchpad.net/bzr/x.y/x.y.z/>
621
 
 
622
640
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
623
641
   be done for the stable and beta releases.
624
642