/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: Jelmer Vernooij
  • Date: 2019-01-02 18:49:15 UTC
  • mto: This revision was merged to the branch mainline in revision 7235.
  • Revision ID: jelmer@jelmer.uk-20190102184915-0da9k4jk49kql994
Fix import for git-objects.

Show diffs side-by-side

added added

removed removed

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