← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Patrick Regan
  • Date: 2009-12-02 20:34:07 UTC
  • mto: (4852.3.3 2.1.0b4-doc-updates)
  • mto: This revision was merged to the branch mainline in revision 4856.
  • Revision ID: patrick.rubbs.regan@gmail.com-20091202203407-fjd0mshgn3j3foel
Removed trailing whitespace from files in doc directory

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 2009-08.
6
6
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
7
7
 
8
8
 
18
18
 
19
19
* `Bazaar Developer Document Catalog <index.html>`_
20
20
 
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.
23
23
 
24
24
The Problem Situation
25
25
*********************
26
26
 
27
27
Bazaar makes a release every month, preceded by a one-week
28
 
release-candidate test.  
 
28
release-candidate test.
29
29
 
30
30
In any release we may fix bugs, add formats, change the default format,
31
31
improve performance, add new commands or change command line behaviour,
105
105
                                                        +-- 3.0.0beta1 ...
106
106
 
107
107
 
108
 
Starting from the date of a major release: 
 
108
Starting from the date of a major release:
109
109
 
110
110
At four-week intervals we make a new beta release.  There will be no
111
111
separate release candidate, but if a serious problem is discovered we may
121
121
We will then make a release candidate for the next major release, and at
122
122
this point create a release branch for it.  We will iterate release
123
123
candidates at approximately weekly intervals until there are no bugs
124
 
blocking the final major release. 
 
124
blocking the final major release.
125
125
 
126
126
Compared to the current process this has approximately the same amount of
127
127
release-related work, because the extra releases from the stable branch
192
192
Bug Work
193
193
--------
194
194
 
195
 
Bug fixes should normally be done first against the stable branch, 
 
195
Bug fixes should normally be done first against the stable branch,
196
196
reviewed against that branch, and then merged forward to trunk.
197
197
 
198
198
It may not always be easy to do this, if fixing the bug requires large
240
240
of bzrlib, which is an elusive target in Python.
241
241
 
242
242
This may mean that in cases where today a plugin would keep running but
243
 
give warnings, it will now fail altogether with an error.   
 
243
give warnings, it will now fail altogether with an error.
244
244
 
245
245
In return we expect more freedom to change and cleanup bzrlib code without
246
246
needing to keep old code around, or write extra compatibility shims, or
252
252
but that aren't technically plugins.  The same approach, though the
253
253
technical considerations are different, should apply to other extensions
254
254
such as programs that use bzr through the shell interface.
255
 
  
 
255
 
256
256
 
257
257
 
258
258
Data and Network Formats
296
296
This can be handled in various ways either at the OS packaging or the
297
297
Python level.  We don't propose to directly address it in the upstream
298
298
source.  (For example, we will not change the bzrlib library name from one
299
 
release to the next.)  
 
299
release to the next.)
300
300
 
301
301
The issue already exists with people who may want to use for example the
302
302
previous bzr release and the trunk.  There is a related issue that plugins
350
350
 
351
351
* Early communication about changing dependencies or defaults
352
352
 
353
 
* 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
354
354
  dates for the next release and/or candidate.
355
355
 
356
356
* Summary of recent successes and pending work.
364
364
Questions
365
365
*********
366
366
 
367
 
Do users actually want this?  
 
367
Do users actually want this?
368
368
    Apparently yes, because it's often requested and often raised as a
369
369
    problem.
370
370
 
371
 
Would this confuse users?  
 
371
Would this confuse users?
372
372
    It shouldn't, because it's a fairly standard scheme.
373
373
 
374
374
Won't it take more time to fix bugs in multiple places?
388
388
    really rather not test them, forcing them is not helpful.
389
389
 
390
390
Isn't this a step backwards to a slower, less-agile process?
391
 
    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
392
392
    cutting out things that hold us back (continuous rather than episodic
393
393
    API stability; RCs every month) and giving users what they demand.
394
394
 
406
406
  and stable releases, indicating that each has value.
407
407
 
408
408
* API changes are easier or safer to make during beta periods, without
409
 
  being held back by fears of compatibility or 
 
409
  being held back by fears of compatibility or
410
410
 
411
411
* The stable releases are actually stable and don't introduce regressions
412
412
  or break plugins.