← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Andrew Bennetts
  • Date: 2010-10-13 08:08:58 UTC
  • mfrom: (5491 +trunk)
  • mto: This revision was merged to the branch mainline in revision 5498.
  • Revision ID: andrew.bennetts@canonical.com-20101013080858-a4pm24k67406qp04
Merge lp:bzr, including significant updates to NEWS.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
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 the
6
 
`overall development cycle <http://doc.bazaar.canonical.com/developers/cycle.html>`_,
7
 
but it's the most complex part.  This document gives a checklist you can
8
 
follow from start to end in one go.
 
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.
9
11
 
10
12
If you're helping the Release Manager (RM) for one reason or another, you
11
13
may notice that he didn't follow that document scrupulously. He may have
25
27
     bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
26
28
 
27
29
 
 
30
When do we relase ?
 
31
===================
 
32
 
 
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).
 
38
 
 
39
In order to continue to do time-based releases, we need to plan the
 
40
releases by series to minimize the collisions. In the end, it's the Release
 
41
Manager call to decide whether he prefers to do all releases at once
 
42
though, so the rules presented here are a conservative approach.
 
43
 
 
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
 
 
79
 
28
80
At the start of a release cycle
29
81
===============================
30
82
 
187
239
 
188
240
      # API compatibility version: bzrlib is currently API compatible with 1.7.
189
241
 
 
242
   Note that the NEWS file formatting has evolved, this example needs to
 
243
   be updated.
 
244
 
190
245
#. Tag the new release::
191
246
 
192
247
     bzr tag bzr-1.14
242
297
   this changes what the download widget on the Launchpad bzr home
243
298
   page shows, so don't stop the release process yet, or platform binary
244
299
   installers won't be made and the download list will stay very small!
245
 
   <https://bugs.edge.launchpad.net/launchpad/+bug/586445>
 
300
   <https://bugs.launchpad.net/launchpad/+bug/586445>
246
301
 
247
302
 
248
303
Announcing the source freeze
249
304
----------------------------
250
305
 
251
 
#. Post to the ``bazaar`` list, saying that the source has been frozen.
252
 
   This is the cue for platform maintainers and plugin authors to update
253
 
   their code.  This is done before the general public announcement of the
254
 
   release.
 
306
#. Post to the ``bazaar`` list, saying that the source has been frozen
 
307
   (gone gold). Be extra clear that this is only a *source* release
 
308
   targeted at packagers and installer builders (see
 
309
   <https://bugs.launchpad.net/launchpad/+bug/645084>).  This is the cue
 
310
   for platform maintainers and plugin authors to update their code.  This
 
311
   is done before the general public announcement of the release.
255
312
 
256
313
 
257
314
Kick off the next cycle
307
364
 
308
365
      Subject: bzr x.y.z released!
309
366
 
310
 
      <<Summary paragraph from news>>
311
 
 
312
367
      The Bazaar team is happy to announce availability of a new
313
368
      release of the bzr adaptive version control system.
314
369
      Bazaar is part of the GNU system <http://gnu.org/>.
315
370
 
 
371
      <<Summary paragraph from news>>
 
372
 
316
373
      Thanks to everyone who contributed patches, suggestions, and
317
374
      feedback.
318
375
 
343
400
 
344
401
       python setup.py register
345
402
 
346
 
   Remember to check the results afterwards.
 
403
   Remember to check the results afterwards -- this should be done for
 
404
   final releases but not for beta releases or Release Candidates.
347
405
 
348
406
   To be able to register the release you must create an account on
349
407
   <http://pypi.python.org/pypi> and have one of the existing owners of