← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-10-13 07:04:50 UTC
  • mfrom: (5447.2.2 work)
  • Revision ID: pqm@pqm.ubuntu.com-20101013070450-xmn9cpnli5qnmrt8
(vila) Tweak the release process based on ML discussion (Vincent Ladeuil)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/cycle.txt
2
2
Bazaar Release Cycles
3
3
*********************
4
4
 
5
 
:status: Current policy, as of 2009-08.
 
5
:status: Current policy, as of 2010-10.
6
6
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
7
7
 
8
8
 
10
10
core product. They also want a Just Works experience across the full
11
11
Bazaar ecosystem. To deliver the first and enable the second, we're
12
12
adopting some standard process patterns: a 6 monthly release cycle and a
13
 
stable branch. These changes will also have other benefits, including
 
13
stable series. These changes will also have other benefits, including
14
14
better availability of bug fixes in OS distributions, more freedom to
15
15
remove old code, and less work for in packaging.
16
16
 
25
25
The Process
26
26
************
27
27
 
28
 
Bazaar will make a major release every six months, which will be supported
29
 
at least until the time of the next major release.  During this support
30
 
period, we'll make incremental releases which fix bugs, but which do not
31
 
change network or disk formats or command syntax, and which do not require
32
 
updates to plugins.
 
28
Bazaar will make a major release every six months, which will be supported at
 
29
least until the time of the next major release and generally 18 months after
 
30
the first final release in a series.  During this support period, we'll make
 
31
incremental releases which fix bugs, but which do not change network or disk
 
32
formats or command syntax, and which do not require updates to plugins.
33
33
 
34
34
We will also run a development series, which will become the next major
35
35
release.  We'll make a beta release from this every four weeks.  The
75
75
often if there are serious bugs, perhaps much less often if no new changes
76
76
have landed.
77
77
 
78
 
We will then make a release candidate for the next major release, and at
79
 
this point create a release branch for it.  We will iterate release
80
 
candidates at approximately weekly intervals until there are no bugs
81
 
blocking the final major release.
82
 
 
83
 
Compared to the current process this has approximately the same amount of
84
 
release-related work, because the extra releases from the stable branch
85
 
are "paid for" by not doing RCs for the development series.
86
 
 
87
78
We will synchronize our major releases with Ubuntu, so that they come out
88
79
in sufficient time for some testing and margin of error before Ubuntu's
89
80
upstream freeze.
118
109
-----------
119
110
 
120
111
Major releases (2.0.0 or 2.1.0)
 
112
 
121
113
    The big ones, every six months, intended to ship in distributions and
122
114
    to be used by stability-oriented users.
123
115
 
124
116
Release candidate (2.0.0rc1)
125
 
    A preview of a major release, made one or a few weeks beforehand at
126
 
    the time the release branch is created.  There should be few if any
127
 
    changes from the rc to the stable release.  We should avoid the
128
 
    confusing phrasing "release candidate 2.0.0rc1 is released"; instead
129
 
    use "available."
 
117
 
 
118
    A preview of a major release, made one or a few weeks beforehand at the
 
119
    time the release branch is created.  There should be few if any changes
 
120
    from the rc to the stable release.  We should avoid the confusing phrasing
 
121
    "release candidate 2.0.0rc1 is released"; instead use "available."
 
122
    Starting with the 2.3 series we don't plan on making release candidates
 
123
    anymore.
130
124
 
131
125
Bugfix releases (2.0.1)
 
126
 
132
127
    Based on the previous major release or bugfix; contains only bugfixes
133
128
    and perhaps documentation or translation corrections.
134
129
 
135
130
Stable series
 
131
 
136
132
    A major release and its descendant bugfix releases.
137
133
 
138
134
Stable release
 
135
 
139
136
    Either a major release or a bugfix release.
140
137
 
141
138
Beta release (3.0.0beta1)
 
139
 
142
140
    Made from trunk every month, except for the month there's a major
143
141
    release.  Stable and suitable for users who want the latest code and
144
142
    can live with some changes from month to month.
145
143
 
146
144
Development series
 
145
 
147
146
    The development releases leading up to a stable release.
148
147
 
149
148
Bug Work
183
182
Plugins that want to cooperate with this should make a series and a branch
184
183
that matches each bzr stable series, and follow similar rules in making
185
184
releases from their stable branch.  We'd expect that plugins will make a
186
 
release between the last development release of a series and the major
187
 
release candidate.
 
185
release between the first beta release of a series and the final major
 
186
release.
188
187
 
189
188
Within a stable series, anything that breaks any known plugin is
190
189
considered an API break and will be avoided.  Before
274
273
Packaging
275
274
---------
276
275
 
277
 
At present we have three upstream-maintained PPAs containing Ubuntu
278
 
packages of Bazaar: ``~bzr-nightly-ppa``, ``~bzr-beta-ppa`` (rcs and
279
 
releases) and ``~bzr`` (ie stable).  We will keep these PPAs, and reorient
280
 
beta to contain the monthly beta releases, and the stable PPA to contain
281
 
stable releases, their release candidates, and bugfixes to those releases.
 
276
At present we have three upstream-maintained PPAs containing Ubuntu packages
 
277
of Bazaar: ``~bzr-nightly-ppa``, ``~bzr-beta-ppa`` (beta releases) and
 
278
``~bzr`` (ie stable).  We will keep these PPAs, and reorient beta to contain
 
279
the monthly beta releases, and the stable PPA to contain stable releases and
 
280
bugfixes to those releases.
282
281
 
283
282
Some platforms with relatively less active packagers may choose to ship
284
283
only the stable releases.  This is probably better than having them only