/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Robert Collins
  • Date: 2010-05-06 11:08:10 UTC
  • mto: This revision was merged to the branch mainline in revision 5223.
  • Revision ID: robertc@robertcollins.net-20100506110810-h3j07fh5gmw54s25
Cleaner matcher matching revised unlocking protocol.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/cycle.txt
1
1
*********************
2
 
Breezy Release Cycles
 
2
Bazaar Release Cycles
3
3
*********************
4
4
 
5
 
:status: Current policy, as of 2017-11.
 
5
:status: Current policy, as of 2009-08.
 
6
:blueprint: <https://blueprints.launchpad.net/bzr/+spec/6m-cycle>
6
7
 
7
8
 
8
9
Our users want easy access to bug fixes without other changes to the
9
10
core product. They also want a Just Works experience across the full
10
 
Breezy ecosystem. To deliver the first and enable the second, we're
 
11
Bazaar ecosystem. To deliver the first and enable the second, we're
11
12
adopting some standard process patterns: a 6 monthly release cycle and a
12
 
stable series. These changes will also have other benefits, including
 
13
stable branch. These changes will also have other benefits, including
13
14
better availability of bug fixes in OS distributions, more freedom to
14
15
remove old code, and less work for in packaging.
15
16
 
16
17
See also:
17
18
 
18
 
* `Breezy Developer Document Catalog <index.html>`_
 
19
* `Bazaar Developer Document Catalog <index.html>`_
19
20
 
20
21
* `Releasing Bazaar <releasing.html>`_ -- the process for actually making
21
22
  a release or release candidate.
24
25
The Process
25
26
************
26
27
 
27
 
Breezy will make a major release every six months, which will be supported at
28
 
least until the time of the next major release and generally 18 months after
29
 
the first final release in a series.  During this support period, we'll make
30
 
incremental releases which fix bugs, but which do not change network or disk
31
 
formats or command syntax, and which do not require updates to plugins.
 
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.
32
33
 
33
34
We will also run a development series, which will become the next major
34
35
release.  We'll make a beta release from this every four weeks.  The
74
75
often if there are serious bugs, perhaps much less often if no new changes
75
76
have landed.
76
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
 
77
87
We will synchronize our major releases with Ubuntu, so that they come out
78
88
in sufficient time for some testing and margin of error before Ubuntu's
79
89
upstream freeze.
108
118
-----------
109
119
 
110
120
Major releases (2.0.0 or 2.1.0)
111
 
 
112
121
    The big ones, every six months, intended to ship in distributions and
113
122
    to be used by stability-oriented users.
114
123
 
115
124
Release candidate (2.0.0rc1)
116
 
 
117
 
    A preview of a major release, made one or a few weeks beforehand at the
118
 
    time the release branch is created.  There should be few if any changes
119
 
    from the rc to the stable release.  We should avoid the confusing phrasing
120
 
    "release candidate 2.0.0rc1 is released"; instead use "available."
121
 
    Starting with the 2.3 series we don't plan on making release candidates
122
 
    anymore.
 
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."
123
130
 
124
131
Bugfix releases (2.0.1)
125
 
 
126
132
    Based on the previous major release or bugfix; contains only bugfixes
127
133
    and perhaps documentation or translation corrections.
128
134
 
129
135
Stable series
130
 
 
131
136
    A major release and its descendant bugfix releases.
132
137
 
133
138
Stable release
134
 
 
135
139
    Either a major release or a bugfix release.
136
140
 
137
141
Beta release (3.0.0beta1)
138
 
 
139
142
    Made from trunk every month, except for the month there's a major
140
143
    release.  Stable and suitable for users who want the latest code and
141
144
    can live with some changes from month to month.
142
145
 
143
146
Development series
144
 
 
145
147
    The development releases leading up to a stable release.
146
148
 
147
149
Bug Work
181
183
Plugins that want to cooperate with this should make a series and a branch
182
184
that matches each bzr stable series, and follow similar rules in making
183
185
releases from their stable branch.  We'd expect that plugins will make a
184
 
release between the first beta release of a series and the final major
185
 
release.
 
186
release between the last development release of a series and the major
 
187
release candidate.
186
188
 
187
189
Within a stable series, anything that breaks any known plugin is
188
190
considered an API break and will be avoided.  Before
192
194
Within a development series, the focus is on helping plugin authors keep
193
195
up to date by giving clear error messages when an interface is removed.
194
196
We will no longer focus on letting old plugin code work with new versions
195
 
of breezy, which is an elusive target in Python.
 
197
of bzrlib, which is an elusive target in Python.
196
198
 
197
199
This may mean that in cases where today a plugin would keep running but
198
200
give warnings, it will now fail altogether with an error.
199
201
 
200
 
In return we expect more freedom to change and cleanup breezy code without
 
202
In return we expect more freedom to change and cleanup bzrlib code without
201
203
needing to keep old code around, or write extra compatibility shims, or
202
204
have review turnarounds related to compatibility.  Some changes, such as
203
205
removing module-global variables, that are hard to do now, will be
204
206
possible to do safely.
205
207
 
206
 
Discussion of plugins here includes programs that import and use breezy
 
208
Discussion of plugins here includes programs that import and use bzrlib
207
209
but that aren't technically plugins.  The same approach, though the
208
210
technical considerations are different, should apply to other extensions
209
211
such as programs that use bzr through the shell interface.
250
252
 
251
253
This can be handled in various ways either at the OS packaging or the
252
254
Python level.  We don't propose to directly address it in the upstream
253
 
source.  (For example, we will not change the breezy library name from one
 
255
source.  (For example, we will not change the bzrlib library name from one
254
256
release to the next.)
255
257
 
256
258
The issue already exists with people who may want to use for example the
272
274
Packaging
273
275
---------
274
276
 
275
 
At present we have three upstream-maintained PPAs containing Ubuntu packages
276
 
of Bazaar: ``bzr/daily`` (snapshots), ``bzr-beta-ppa/ppa`` (beta releases) and
277
 
``bzr/ppa`` (ie stable).  Beta contains the monthly beta releases, and the
278
 
stable PPA contains stable releases and bugfixes to those releases.
 
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.
279
282
 
280
283
Some platforms with relatively less active packagers may choose to ship
281
284
only the stable releases.  This is probably better than having them only