← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2009-09-18 16:04:54 UTC
  • mfrom: (4699.2.2 jam-integration)
  • Revision ID: pqm@pqm.ubuntu.com-20090918160454-ag1zd9txn44prlye
(jam) Bring in a couple small patches from the 2.0 branch (such as
        the 2.0.0 fix)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/cycle.txt
97
97
 
98
98
::
99
99
 
100
 
 2.0 --- 2.0.1 -- 2.0.2 -- ...
 
100
 2.0.0 --- 2.0.1 -- 2.0.2 -- ...
101
101
  \
102
 
   +--2.1beta1 -- 2.1beta2 -- ... -- 2.1rc1 -- 2.1 -- 2.1.1 -- ...
103
 
                                                \
104
 
                                                 \
105
 
                                                  +-- 3.0beta1 ...
 
102
   +--2.1.0beta1 -- 2.1.0beta2 -- ... -- 2.1.0rc1 -- 2.1.0 -- 2.1.1 -- ...
 
103
                                                      \
 
104
                                                       \
 
105
                                                        +-- 3.0.0beta1 ...
106
106
 
107
107
 
108
108
Starting from the date of a major release: 
144
144
---------
145
145
 
146
146
The number for a six-month cycle is chosen at the start, with an increment
147
 
to either the first field (3.0) or second field (3.1) depending on what we
148
 
expect to be the user impact of the release.  We expect releases that
149
 
culminate in a new disk format or that require changes in how people use
150
 
the tool will get a new major number.  We can change (forward only) if it
151
 
turns out that we land larger changes than were expected.
 
147
to either the first field (3.0.0) or second field (3.1.0) depending on
 
148
what we expect to be the user impact of the release.  We expect releases
 
149
that culminate in a new disk format or that require changes in how people
 
150
use the tool will get a new major number.  We can change (forward only) if
 
151
it turns out that we land larger changes than were expected.
 
152
 
 
153
We will always use the 3-digit form (major.minor.micro) even when
 
154
referring to the initial major release. This should help clarify where a
 
155
patch is intended to land. (eg, "I propose this for 2.0.0" is clear, while
 
156
"I propose this for 2.0" could mean you want to make the 2.0.0 release, or
 
157
that you just want to land on the 2.0.x stable release series.)
152
158
 
153
159
 
154
160
Terminology
155
161
-----------
156
162
 
157
 
Major releases (2.0 or 2.1)
 
163
Major releases (2.0.0 or 2.1.0)
158
164
    The big ones, every six months, intended to ship in distributions and
159
165
    to be used by stability-oriented users.
160
166
 
161
 
Release candidate (2.0rc1)
 
167
Release candidate (2.0.0rc1)
162
168
    A preview of a major release, made one or a few weeks beforehand at
163
169
    the time the release branch is created.  There should be few if any
164
170
    changes from the rc to the stable release.  We should avoid the
165
 
    confusing phrasing "release candidate 2.0rc1 is released"; instead use
166
 
    "available."
 
171
    confusing phrasing "release candidate 2.0.0rc1 is released"; instead
 
172
    use "available."
167
173
 
168
174
Bugfix releases (2.0.1)
169
175
    Based on the previous major release or bugfix; contains only bugfixes
175
181
Stable release
176
182
    Either a major release or a bugfix release.
177
183
 
178
 
Beta release (3.0beta1)
 
184
Beta release (3.0.0beta1)
179
185
    Made from trunk every month, except for the month there's a major
180
186
    release.  Stable and suitable for users who want the latest code and
181
187
    can live with some changes from month to month.
260
266
Each major release will have one recommended data format which will be the
261
267
default.  The name of the format will indicate which release series (not
262
268
specific release) it comes from: '2a' is the first supported format for
263
 
the 2.0 series, '2b' the second, etc.  We don't mention the particular
 
269
the 2.0.x series, '2b' the second, etc.  We don't mention the particular
264
270
release that introduced it so as to avoid problems predicting precisely
265
271
when it will land.
266
272
 
321
327
only the stable releases.  This is probably better than having them only
322
328
intermittently or slowly ship the monthly releases.
323
329
 
324
 
Binary installers should use a version number like '2.0-1' or '2.0beta1-1'
325
 
so that the last component just reflects the packaging version, and can be
326
 
incremented if a new installer is made with no upstream source changes.
 
330
Binary installers should use a version number like '2.0.0-1' or
 
331
'2.0.0beta1-1' so that the last component just reflects the packaging
 
332
version, and can be incremented if a new installer is made with no
 
333
upstream source changes.
327
334
 
328
335
 
329
336
Code Freeze vs Announcement