← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/cycle.txt

  • Committer: Robert Collins
  • Date: 2007-07-15 15:40:37 UTC
  • mto: (2592.3.33 repository)
  • mto: This revision was merged to the branch mainline in revision 2624.
  • Revision ID: robertc@robertcollins.net-20070715154037-3ar8g89decddc9su
Make GraphIndex accept nodes as key, value, references, so that the method
signature is closer to what a simple key->value index delivers. Also
change the behaviour when the reference list count is zero to accept
key, value as nodes, and emit key, value to make it identical in that case
to a simple key->value index. This may not be a good idea, but for now it
seems ok.

Show diffs side-by-side

added added

removed removed

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