← 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-05-06 04:07:37 UTC
  • mfrom: (4332.1.1 integration)
  • Revision ID: pqm@pqm.ubuntu.com-20090506040737-tdiqyojy2uia33qb
Make it easier to blackbox test rules (Marius Kruger)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/cycle.txt
 
1
The Bazaar Development Cycle
 
2
============================
 
3
 
 
4
 
 
5
 
 
6
General process
 
7
---------------
 
8
 
 
9
We normally have one person acting as the release manager, who 
 
10
organizes development for the release and also actually makes the release
 
11
tarball and posts announcements.  It can be a different person from one
 
12
release to the next.
 
13
 
 
14
Our usual process is that one week before release we will make a release
 
15
branch from the trunk.  We do one commit to that branch to change the
 
16
version number to 'rc1', and advance the trunk version to 'dev' for the
 
17
next release.
 
18
 
 
19
We then publish and announce this release candidate according to the
 
20
process below.  We then have a week of general testing of the rc,
 
21
including some time for plugin authors to update their code for any
 
22
changes.
 
23
 
 
24
Normally no changes will be made on the release branch unless serious bugs
 
25
or regressions are found, and the release manager decides they should be
 
26
merged in.  After one week, the release branch's version number is updated
 
27
and it's published as the final release.  If regressions or serious
 
28
problems are discovered after the final release we may make an additional
 
29
point release from that branch.
 
30
 
 
31
The process or timing can vary if that seems appropriate in a particular
 
32
case but we try to release on a regular four week cycle.
 
33
 
 
34
The net effect is that the code gets some extra testing before release,
 
35
and the trunk is always open for general development.
 
36
 
 
37
 
 
38
Starting a Release
 
39
------------------
 
40
 
 
41
To start a new release cycle:
 
42
 
 
43
#. Send mail to the list with the key dates, who will be the release
 
44
   manager, and the main themes or targetted bugs.  Ask people to nominate
 
45
   objectives, or point out any high-risk things that are best done early,
 
46
   or that interact with other changes.
 
47
 
 
48
#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>.  
 
49
   There is one series for every *x.y* release.
 
50
 
 
51
#. Add milestones to that series for the release candidate and the final
 
52
   release, and their expected dates.
 
53
 
 
54
#. Deactivate old releases and their milestones.
 
55
 
 
56
#. Update the version number in the ``bzr`` script, and the
 
57
   ``bzrlib/__init__.py`` file.
 
58
 
 
59
 
 
60
Weekly Metronome Mail
 
61
---------------------
 
62
 
 
63
Every week the release manager should send a mail to the Bazaar list
 
64
covering these points (as appropriate):
 
65
 
 
66
* Early communication about changing dependencies or defaults
 
67
 
 
68
* Reminder re lifecycle and where we're up to right now, in particular the 
 
69
  dates for the next release and/or candidate.
 
70
 
 
71
* Summary of recent successes and pending work.
 
72
 
 
73
* Reminder re release objectives
 
74
 
 
75
* Reminder re things needing attention, e.g. bug triage, reviews, testing
 
76
  of certain things, etc.
 
77
 
 
78
 
 
79
Starting the release phase
 
80
--------------------------
 
81
 
 
82
When it's time to make the release candidate:
 
83
 
 
84
#. We create a new pqm-controlled branch for this release series.  The
 
85
   branch must be created by Robert Collins on the pqm server.  
 
86
   This branch means that from the first release candidate onwards,
 
87
   general development continues on the trunk, and only
 
88
   specifically-targetted fixes go into the release.
 
89
 
 
90
#. Register the branch at <https://launchpad.net/products/bzr/+addbranch>
 
91
 
 
92
#. The revision at the start of that branch is `released
 
93
   <releasing.html>`_ as the first RC.
 
94
 
 
95
 
 
96
See also
 
97
--------
 
98
 
 
99
* `Bazaar Developer Document Catalog <index.html>`_
 
100
 
 
101
* `Releasing Bazaar <releasing.html>`_ -- the process for actually making 
 
102
  a release or release candidate.
 
103
 
 
104
 
 
105
..
 
106
   vim: filetype=rst textwidth=74 ai shiftwidth=4