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.
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.
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
34
34
We will also run a development series, which will become the next major
35
35
release. We'll make a beta release from this every four weeks. The
75
75
often if there are serious bugs, perhaps much less often if no new changes
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.
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.
78
87
We will synchronize our major releases with Ubuntu, so that they come out
79
88
in sufficient time for some testing and margin of error before Ubuntu's
111
120
Major releases (2.0.0 or 2.1.0)
113
121
The big ones, every six months, intended to ship in distributions and
114
122
to be used by stability-oriented users.
116
124
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
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
125
131
Bugfix releases (2.0.1)
127
132
Based on the previous major release or bugfix; contains only bugfixes
128
133
and perhaps documentation or translation corrections.
132
136
A major release and its descendant bugfix releases.
136
139
Either a major release or a bugfix release.
138
141
Beta release (3.0.0beta1)
140
142
Made from trunk every month, except for the month there's a major
141
143
release. Stable and suitable for users who want the latest code and
142
144
can live with some changes from month to month.
144
146
Development series
146
147
The development releases leading up to a stable release.
182
183
Plugins that want to cooperate with this should make a series and a branch
183
184
that matches each bzr stable series, and follow similar rules in making
184
185
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
186
release between the last development release of a series and the major
188
189
Within a stable series, anything that breaks any known plugin is
189
190
considered an API break and will be avoided. Before
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.
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.
281
283
Some platforms with relatively less active packagers may choose to ship
282
284
only the stable releases. This is probably better than having them only
added
removed
doc/developers/cycle.txt
