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 series. These changes will also have other benefits, including
13
stable branch. 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.
19
19
* `Bazaar Developer Document Catalog <index.html>`_
21
* `Releasing Bazaar <releasing.html>`_ -- the process for actually making
21
* `Releasing Bazaar <releasing.html>`_ -- the process for actually making
22
22
a release or release candidate.
27
Bazaar makes a release every month, preceded by a one-week
28
release-candidate test.
30
In any release we may fix bugs, add formats, change the default format,
31
improve performance, add new commands or change command line behaviour,
32
change the network protocol, or deprecate APIs. We sometimes also
33
introduce new bugs, regress existing behaviour or performance, remove
34
existing features or formats, or break behaviour or APIs depended upon by
35
plugins, external programs or users.
37
Some users are happy upgrading every month and consider the overall
38
positive balance of changes is worth some amount of churn. But there are
39
some serious problems:
41
* You cannot get bug fixes without also getting disruptive changes.
43
* Bazaar is seen as unstable.
45
* Many releases cause some plugin breakage.
47
* One month is not a very long window for dependent programs or systems
48
to catch up to changes in Bazaar before the release goes out of date.
50
* There's no clear indication to distributions which version they should
53
* If people (or their distributions) just pick an arbitrary version, they
54
may all be on different arbitrary versions, therefore they will have
55
different behaviour and different bugs, and sometimes interoperation
58
* Any effort we, or distributors, wanted to put into backporting fixes
59
would be dissipated across many possible backport target releases.
61
* When in the past we've tried either stalling releases for particular
62
features, or having trunk frozen for some weeks, it causes churn and
63
waste. People rush features in, or already landed features wait a long
64
time to be released, or branches go out of date because they cannot
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.
71
Bazaar will make a major release every six months, which will be supported
72
at least until the time of the next major release. During this support
73
period, we'll make incremental releases which fix bugs, but which do not
74
change network or disk formats or command syntax, and which do not require
34
77
We will also run a development series, which will become the next major
35
78
release. We'll make a beta release from this every four weeks. The
57
2.0.0 --- 2.0.1 -- 2.0.2 -- ...
100
2.0 --- 2.0.1 -- 2.0.2 -- ...
59
+--2.1.0beta1 -- 2.1.0beta2 -- ... -- 2.1.0rc1 -- 2.1.0 -- 2.1.1 -- ...
65
Starting from the date of a major release:
102
+--2.1beta1 -- 2.1beta2 -- ... -- 2.1rc1 -- 2.1 -- 2.1.1 -- ...
108
Starting from the date of a major release:
67
110
At four-week intervals we make a new beta release. There will be no
68
111
separate release candidate, but if a serious problem is discovered we may
75
118
often if there are serious bugs, perhaps much less often if no new changes
121
We will then make a release candidate for the next major release, and at
122
this point create a release branch for it. We will iterate release
123
candidates at approximately weekly intervals until there are no bugs
124
blocking the final major release.
126
Compared to the current process this has approximately the same amount of
127
release-related work, because the extra releases from the stable branch
128
are "paid for" by not doing RCs for the development series.
78
130
We will synchronize our major releases with Ubuntu, so that they come out
79
131
in sufficient time for some testing and margin of error before Ubuntu's
94
146
The number for a six-month cycle is chosen at the start, with an increment
95
to either the first field (3.0.0) or second field (3.1.0) depending on
96
what we expect to be the user impact of the release. We expect releases
97
that culminate in a new disk format or that require changes in how people
98
use the tool will get a new major number. We can change (forward only) if
99
it turns out that we land larger changes than were expected.
101
We will always use the 3-digit form (major.minor.micro) even when
102
referring to the initial major release. This should help clarify where a
103
patch is intended to land. (eg, "I propose this for 2.0.0" is clear, while
104
"I propose this for 2.0" could mean you want to make the 2.0.0 release, or
105
that you just want to land on the 2.0.x stable release series.)
147
to either the first field (3.0) or second field (3.1) depending on what we
148
expect to be the user impact of the release. We expect releases that
149
culminate in a new disk format or that require changes in how people use
150
the tool will get a new major number. We can change (forward only) if it
151
turns out that we land larger changes than were expected.
111
Major releases (2.0.0 or 2.1.0)
157
Major releases (2.0 or 2.1)
113
158
The big ones, every six months, intended to ship in distributions and
114
159
to be used by stability-oriented users.
116
Release candidate (2.0.0rc1)
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
161
Release candidate (2.0rc1)
162
A preview of a major release, made one or a few weeks beforehand at
163
the time the release branch is created. There should be few if any
164
changes from the rc to the stable release. We should avoid the
165
confusing phrasing "release candidate 2.0rc1 is released"; instead use
125
168
Bugfix releases (2.0.1)
127
169
Based on the previous major release or bugfix; contains only bugfixes
128
170
and perhaps documentation or translation corrections.
132
173
A major release and its descendant bugfix releases.
136
176
Either a major release or a bugfix release.
138
Beta release (3.0.0beta1)
178
Beta release (3.0beta1)
140
179
Made from trunk every month, except for the month there's a major
141
180
release. Stable and suitable for users who want the latest code and
142
181
can live with some changes from month to month.
144
183
Development series
146
184
The development releases leading up to a stable release.
151
Bug fixes should normally be done first against the stable branch,
189
Bug fixes should normally be done first against the stable branch,
152
190
reviewed against that branch, and then merged forward to trunk.
154
192
It may not always be easy to do this, if fixing the bug requires large
182
220
Plugins that want to cooperate with this should make a series and a branch
183
221
that matches each bzr stable series, and follow similar rules in making
184
222
releases from their stable branch. We'd expect that plugins will make a
185
release between the first beta release of a series and the final major
223
release between the last development release of a series and the major
188
226
Within a stable series, anything that breaks any known plugin is
189
227
considered an API break and will be avoided. Before
196
234
of bzrlib, which is an elusive target in Python.
198
236
This may mean that in cases where today a plugin would keep running but
199
give warnings, it will now fail altogether with an error.
237
give warnings, it will now fail altogether with an error.
201
239
In return we expect more freedom to change and cleanup bzrlib code without
202
240
needing to keep old code around, or write extra compatibility shims, or
222
260
Each major release will have one recommended data format which will be the
223
261
default. The name of the format will indicate which release series (not
224
262
specific release) it comes from: '2a' is the first supported format for
225
the 2.0.x series, '2b' the second, etc. We don't mention the particular
263
the 2.0 series, '2b' the second, etc. We don't mention the particular
226
264
release that introduced it so as to avoid problems predicting precisely
227
265
when it will land.
276
At present we have three upstream-maintained PPAs containing Ubuntu packages
277
of Bazaar: ``bzr/daily`` (snapshots), ``bzr-beta-ppa/ppa`` (beta releases) and
278
``bzr/ppa`` (ie stable). Beta contains the monthly beta releases, and the
279
stable PPA contains stable releases and bugfixes to those releases.
314
At present we have three upstream-maintained PPAs containing Ubuntu
315
packages of Bazaar: ``~bzr-nightly-ppa``, ``~bzr-beta-ppa`` (rcs and
316
releases) and ``~bzr`` (ie stable). We will keep these PPAs, and reorient
317
beta to contain the monthly beta releases, and the stable PPA to contain
318
stable releases, their release candidates, and bugfixes to those releases.
281
320
Some platforms with relatively less active packagers may choose to ship
282
321
only the stable releases. This is probably better than having them only
283
322
intermittently or slowly ship the monthly releases.
285
Binary installers should use a version number like '2.0.0-1' or
286
'2.0.0beta1-1' so that the last component just reflects the packaging
287
version, and can be incremented if a new installer is made with no
288
upstream source changes.
324
Binary installers should use a version number like '2.0-1' or '2.0beta1-1'
325
so that the last component just reflects the packaging version, and can be
326
incremented if a new installer is made with no upstream source changes.
291
329
Code Freeze vs Announcement
322
Do users actually want this?
360
Do users actually want this?
323
361
Apparently yes, because it's often requested and often raised as a
326
Would this confuse users?
364
Would this confuse users?
327
365
It shouldn't, because it's a fairly standard scheme.
329
367
Won't it take more time to fix bugs in multiple places?
343
381
really rather not test them, forcing them is not helpful.
345
383
Isn't this a step backwards to a slower, less-agile process?
346
No, our trunk stays releasable, and we ship every month. We're just
384
No, our trunk stays releasable, and we ship every month. We're just
347
385
cutting out things that hold us back (continuous rather than episodic
348
386
API stability; RCs every month) and giving users what they demand.
379
After doing this for the 2.0 cycle (September 2009 through to early
380
2010), it seems to be going well.
383
Reviewing for the Stable Branch
384
*******************************
386
These are guidelines and can be interpreted case-by-case.
388
* All changes to the stable branch should fix a bug, even if you would not
389
normally file a bug for the change. The bug description should if at
390
all possible explain how to manually verify the bug in a way that will
391
fail before and pass after the change. (These are requirements for the
394
* The change should be reasonably small and conservative.
396
* Remember that the patch will be read during the SRU
397
process and so keeping the patch small is useful even beyond keeping the
398
logical changes small. Avoid doing mechanical bulk changes on the
401
* Use particular care for things that may behave differently across
402
platforms, encodings or locales. It's harder to thoroughly test these
403
things before a release.
405
* Generally speaking, just cleaning things up is not a sufficient reason
406
to make changes to the stable branch. It has to actually fix a bug.
408
* Changes to the stable branch should include tests as usual.
410
* Don't change or remove existing APIs that might be used by plugins, even
411
if they are underscore-prefixed. Adding APIs that are also being added
412
to the trunk branch may make sense.
414
* Keeping consistency with trunk is useful, but less important than
415
keeping the stable branch stable.
417
* (more items welcome)
422
#. List thread "`[rfc] six-month stable release cycles`__", July 2009.
424
.. __: https://lists.ubuntu.com/archives/bazaar/2009q3/060882.html
420
#. List thread "[rfc] six-month stable release cycles", July 2009.
427
423
vim: filetype=rst textwidth=74 ai shiftwidth=4
added
removed
doc/developers/cycle.txt
