← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: John Arbash Meinel
  • Date: 2009-11-30 17:25:22 UTC
  • mto: This revision was merged to the branch mainline in revision 4849.
  • Revision ID: john@arbash-meinel.com-20091130172522-m373yel3msmjppey
Implement KnownGraph.add_node() for the pyrex version.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/releasing.txt
2
2
================
3
3
 
4
4
This document describes the processes for making and announcing a Bazaar
5
 
release, and managing the release process.  This is just one phase of the
 
5
release, and managing the release process.  This is just one phase of the 
6
6
`overall development cycle <http://doc.bazaar-vcs.org/developers/cycle.html>`_,
7
7
but it's the most complex part.
8
8
This document gives a checklist you can follow from start to end in one
42
42
   will be available for targeting or nominating bugs.
43
43
 
44
44
#. We create a new pqm-controlled branch for this release series, by
45
 
   asking a Canonical sysadmin.
 
45
   asking a Canonical sysadmin.  
46
46
   This branch means that from the first release beta or candidate onwards,
47
47
   general development continues on the trunk, and only
48
48
   specifically-targeted fixes go into the release branch.
61
61
   or that interact with other changes. This is called the metronome mail
62
62
   and is described in `Development cycles <cycle.html>`_.
63
63
 
64
 
#. Make a local branch for preparing this release.  (Only for the first
 
64
#. Make a local branch for preparing this release.  (Only for the first 
65
65
   release in a series, otherwise you should already have a branch.) ::
66
66
 
67
67
     bzr branch trunk prepare-1.14
104
104
 
105
105
#. Add the date and release number to ``./NEWS``
106
106
 
107
 
   Depending on whether you're doing a beta or a bugfix release, you'll
108
 
   have to create a NEWS section for your release in the right
109
 
   place. Most of the time, the new section is at the top of the file
110
 
   (look what have been done for the various 2.0x and 2.1.0bx releases).
111
 
   The rule is to keep the sections sorted by date. You'll need to be
112
 
   cautious when merging back to trunk to respect that.
 
107
   What order to we keep here ? By major release or by date ? The bugfix
 
108
   release are likely to occur after the next major release has
 
109
   occurred. The workflow says that we should keep them sorted by release
 
110
   but that may be a bit disturbing for users reading the NEWS. Anyaw we
 
111
   should chose one and document it.
 
112
  
113
113
 
114
114
#. To check that all bugs mentioned in ``./NEWS`` are actually marked as
115
115
   closed in Launchpad, you can run ``tools/check-newsbugs.py``::
123
123
#. Summarize into one or two paragraphs what's new in this release.
124
124
 
125
125
#. Commit these changes to the release branch, using a command like::
126
 
 
127
 
     bzr commit -m "Release 1.14."
128
 
 
 
126
    
 
127
     bzr commit -m "Release 1.14." 
 
128
   
129
129
   The diff before you commit will be something like::
130
130
 
131
131
     === modified file 'NEWS'
132
132
     --- NEWS        2008-09-17 23:09:18 +0000
133
133
     +++ NEWS        2008-09-23 16:14:54 +0000
134
134
     @@ -4,6 +4,23 @@
135
 
 
 
135
     
136
136
      .. contents::
137
 
 
 
137
     
138
138
     +bzr 1.7 2008-09-23
139
139
     +------------------
140
140
     +
147
147
     +
148
148
      bzr 1.7rc2 2008-09-17
149
149
      ---------------------
150
 
 
151
 
 
 
150
     
 
151
     
152
152
     === modified file 'bzrlib/__init__.py'
153
153
     --- bzrlib/__init__.py  2008-09-16 21:39:28 +0000
154
154
     +++ bzrlib/__init__.py  2008-09-23 16:14:54 +0000
155
155
     @@ -41,7 +41,7 @@
156
156
      # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
157
157
      # releaselevel of 'dev' for unreleased under-development code.
158
 
 
 
158
     
159
159
     -version_info = (1, 7, 0, 'candidate', 2)
160
160
     +version_info = (1, 7, 0, 'final', 0)
161
 
 
162
 
 
 
161
     
 
162
     
163
163
      # API compatibility version: bzrlib is currently API compatible with 1.7.
164
 
 
 
164
      
165
165
#. Tag the new release::
166
166
 
167
167
     bzr tag bzr-1.14
170
170
   the Internet. PQM will pull from this repository when it attempts to merge
171
171
   your changes. Then submit those changes to PQM for merge into the
172
172
   appropriate release branch::
173
 
 
 
173
 
174
174
     bzr push
175
175
     bzr pqm-submit -m "(mbp) prepare 1.14"
176
176
 
181
181
-------------------------
182
182
 
183
183
#. Change into the source directory and run ::
184
 
 
 
184
  
185
185
     make dist
186
186
 
187
187
#. Now we'll try expanding this tarball and running the test suite
188
188
   to check for packaging problems::
189
 
 
 
189
 
190
190
     make check-dist-tarball
191
191
 
192
192
   You may encounter failures while running the test suite caused
259
259
   ``bazaar-announce`` list too.
260
260
 
261
261
   For final releases, it should also be cc'd to ``info-gnu@gnu.org``,
262
 
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.
 
262
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.  
263
263
 
264
264
   In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
265
265
   so that people who reply to the announcement don't spam other lists.
266
266
 
267
267
   The announce mail will look something like this::
268
 
 
 
268
   
269
269
      Subject: bzr x.yy released!
270
 
 
 
270
      
271
271
      <<Summary paragraph from news>>
272
 
 
273
 
      The Bazaar team is happy to announce availability of a new
 
272
     
 
273
      The Bazaar team is happy to announce availability of a new 
274
274
      release of the bzr adaptive version control system.
275
275
      Bazaar is part of the GNU system <http://gnu.org/>.
276
 
 
 
276
     
277
277
      Thanks to everyone who contributed patches, suggestions, and
278
278
      feedback.
279
 
 
280
 
      Bazaar is now available for download from
281
 
      http://bazaar-vcs.org/Download as a source tarball; packages
 
279
      
 
280
      Bazaar is now available for download from 
 
281
      http://bazaar-vcs.org/Download as a source tarball; packages 
282
282
      for various systems will be available soon.
283
 
 
 
283
      
284
284
      <<NEWS section from this release back to the last major release>>
285
285
 
286
286
   Feel free to tweak this to your taste.
291
291
   ensuring the new topic text keeps the project name, web site link, etc.
292
292
 
293
293
#. Announce on http://freshmeat.net/projects/bzr/
294
 
 
 
294
   
295
295
   This should be done for beta releases, release candidates and final
296
296
   releases. If you do not have a Freshmeat account yet, ask one of the
297
297
   existing admins.