← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Vincent Ladeuil
  • Date: 2010-10-12 15:50:39 UTC
  • mto: This revision was merged to the branch mainline in revision 5491.
  • Revision ID: v.ladeuil+lp@free.fr-20101012155039-mkar8mft788azp7i
More updates following list discussion.

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
24
26
 
25
27
     bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm
26
28
 
27
 
Release provisional planning
28
 
============================
29
 
 
30
 
We currently maintain four series. Concurrently releasing them all at the
31
 
same time makes it harder to shorten the delay between the source
32
 
availability and the package building longer than necessary (we delay the
33
 
official announcement until most of our users can install the new release).
 
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).
34
38
 
35
39
In order to continue to do time-based releases, we need to plan the
36
 
releases by series to minimize the collisions.
 
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.
37
43
 
38
44
We want to respect the following rules::
39
45
 
40
 
 * the most recent series should release once a month,
41
 
 
42
 
 * the most recent stable series should release every other month (based
43
 
   on the amount of bug fixes, this can be shorter or longer depending
44
 
   on the bugs importance),
45
 
 
46
 
 * previous series should relesase on a a regular basis without
47
 
   interfering with the most recent series with a decreasing order of
48
 
   priority (again this should be based on bugs importance and user
49
 
   feedback,
50
 
 
51
 
 * the death of a series should be planned ahead of time. 6 months
52
 
   should give enough time to our users to migrate to a more recent
53
 
   series,
54
 
 
55
 
 * there should not be more than 2 releases in the same week (but the
56
 
   Release Manager is free to ignore this (get in touch with packagers
57
 
   though),
58
 
 
59
 
 * the series are aligned with Ubuntu releases for convenience since we
60
 
   create a new series every 6 months. This means that we support the
61
 
   stable series for 2 years. Note that we also propose the most recent
62
 
   stable series via the ppa, so whether we keep supporting LTS directly
63
 
   or via the ppa is still an open question.
64
 
 
65
 
 
66
 
2.3 series
67
 
----------
68
 
 
69
 
The 2.3 series has entered the beta phase and 2.3.0 should be released soon
70
 
enough to be included into Natty Narwhal. This gives the following expected
71
 
releases::
72
 
 
73
 
 * 2.3.0: 2011-02-03
74
 
 
75
 
 * 2.3rc2: 2011-01-06
76
 
 
77
 
 * 2.3rc1: 2010-12-02
78
 
 
79
 
 * 2.3b3: 2010-11-04
80
 
 
81
 
 * 2.3b2: 2010-10-08
82
 
 
83
 
 * 2.3.b1: 2010-09-19
84
 
 
85
 
2.2 series
86
 
----------
87
 
 
88
 
The 2.2 series is the current stable release and is included in Maverick
89
 
Meerkat. The planned releases are::
90
 
 
91
 
 * 2.2.3: 2010-12-16
92
 
 
93
 
 * 2.2.2: 2010-11-18
94
 
 
95
 
 * 2.2.1: 2010-09-17
96
 
 
97
 
 * 2.2.0: 2010-08-06
98
 
 
99
 
 
100
 
2.1 series
101
 
----------
102
 
 
103
 
The 2.1 series is the stable release included in Lucid Lynx. The planned
104
 
releases are::
105
 
 
106
 
 * 2.1.6: 2011-01
107
 
 
108
 
 * 2.1.5: 2010-12
109
 
 
110
 
 * 2.1.4: 2010-11
111
 
 
112
 
 * 2.1.3: 2010-09-16
113
 
 
114
 
 * 2.1.2: 2010-05-27
115
 
 
116
 
 * 2.1.1: 2010-03-02
117
 
 
118
 
 * 2.1.0: 2010-02-11
119
 
 
120
 
 
121
 
2.0 series
122
 
----------
123
 
 
124
 
The 2.0 series is the stable release included in Karmic Koala. The planned
125
 
release are::
126
 
 
127
 
 * 2.0.7: 2011-03 will be the last release for the 2.0 series.
128
 
 
129
 
 * 2.0.6: 2010-09-16
130
 
 
131
 
 * 2.0.5: 2010-03-22
132
 
 
133
 
 * 2.0.4: 2010-01-21
134
 
 
135
 
 * 2.0.3: 2009-12-14
136
 
 
137
 
 * 2.0.2: 2009-11-02
138
 
 
139
 
 * 2.0.1: 2009-10-14
140
 
 
141
 
 * 2.0.0: 2009-09-21
 
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.
142
78
 
143
79
 
144
80
At the start of a release cycle
457
393
 
458
394
       python setup.py register
459
395
 
460
 
   Remember to check the results afterwards.
 
396
   Remember to check the results afterwards -- this should be done for
 
397
   final releases but not for beta releases or Release Candidates.
461
398
 
462
399
   To be able to register the release you must create an account on
463
400
   <http://pypi.python.org/pypi> and have one of the existing owners of