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
62
105
+-- 3.0.0beta1 ...
65
Starting from the date of a major release:
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
78
121
We will then make a release candidate for the next major release, and at
79
122
this point create a release branch for it. We will iterate release
80
123
candidates at approximately weekly intervals until there are no bugs
81
blocking the final major release.
124
blocking the final major release.
83
126
Compared to the current process this has approximately the same amount of
84
127
release-related work, because the extra releases from the stable branch
152
Bug fixes should normally be done first against the stable branch,
195
Bug fixes should normally be done first against the stable branch,
153
196
reviewed against that branch, and then merged forward to trunk.
155
198
It may not always be easy to do this, if fixing the bug requires large
197
240
of bzrlib, which is an elusive target in Python.
199
242
This may mean that in cases where today a plugin would keep running but
200
give warnings, it will now fail altogether with an error.
243
give warnings, it will now fail altogether with an error.
202
245
In return we expect more freedom to change and cleanup bzrlib code without
203
246
needing to keep old code around, or write extra compatibility shims, or
253
296
This can be handled in various ways either at the OS packaging or the
254
297
Python level. We don't propose to directly address it in the upstream
255
298
source. (For example, we will not change the bzrlib library name from one
256
release to the next.)
299
release to the next.)
258
301
The issue already exists with people who may want to use for example the
259
302
previous bzr release and the trunk. There is a related issue that plugins
308
351
* Early communication about changing dependencies or defaults
310
* Reminder re lifecycle and where we're up to right now, in particular the
353
* Reminder re lifecycle and where we're up to right now, in particular the
311
354
dates for the next release and/or candidate.
313
356
* Summary of recent successes and pending work.
324
Do users actually want this?
367
Do users actually want this?
325
368
Apparently yes, because it's often requested and often raised as a
328
Would this confuse users?
371
Would this confuse users?
329
372
It shouldn't, because it's a fairly standard scheme.
331
374
Won't it take more time to fix bugs in multiple places?
345
388
really rather not test them, forcing them is not helpful.
347
390
Isn't this a step backwards to a slower, less-agile process?
348
No, our trunk stays releasable, and we ship every month. We're just
391
No, our trunk stays releasable, and we ship every month. We're just
349
392
cutting out things that hold us back (continuous rather than episodic
350
393
API stability; RCs every month) and giving users what they demand.
363
406
and stable releases, indicating that each has value.
365
408
* API changes are easier or safer to make during beta periods, without
366
being held back by fears of compatibility or
409
being held back by fears of compatibility or
368
411
* The stable releases are actually stable and don't introduce regressions
369
412
or break plugins.
381
After doing this for the 2.0 cycle (September 2009 through to early
382
2010), it seems to be going well.
385
Reviewing for the Stable Branch
386
*******************************
388
These are guidelines and can be interpreted case-by-case.
390
* All changes to the stable branch should fix a bug, even if you would not
391
normally file a bug for the change. The bug description should if at
392
all possible explain how to manually verify the bug in a way that will
393
fail before and pass after the change. (These are requirements for the
396
* The change should be reasonably small and conservative.
398
* Remember that the patch will be read during the SRU
399
process and so keeping the patch small is useful even beyond keeping the
400
logical changes small. Avoid doing mechanical bulk changes on the
403
* Use particular care for things that may behave differently across
404
platforms, encodings or locales. It's harder to thoroughly test these
405
things before a release.
407
* Generally speaking, just cleaning things up is not a sufficient reason
408
to make changes to the stable branch. It has to actually fix a bug.
410
* Changes to the stable branch should include tests as usual.
412
* Don't change or remove existing APIs that might be used by plugins, even
413
if they are underscore-prefixed. Adding APIs that are also being added
414
to the trunk branch may make sense.
416
* Keeping consistency with trunk is useful, but less important than
417
keeping the stable branch stable.
419
* (more items welcome)
424
#. List thread "`[rfc] six-month stable release cycles`__", July 2009.
426
.. __: https://lists.ubuntu.com/archives/bazaar/2009q3/060882.html
427
#. List thread "[rfc] six-month stable release cycles", July 2009.
429
430
vim: filetype=rst textwidth=74 ai shiftwidth=4
added
removed
doc/developers/cycle.txt
