~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-12-02 23:09:40 UTC
  • mfrom: (4853.1.1 whitespace)
  • mto: This revision was merged to the branch mainline in revision 4856.
  • Revision ID: john@arbash-meinel.com-20091202230940-7n2aydoxngdqxzld
Strip trailing whitespace from doc files by Patrick Regan.

Resolve one small conflict with another doc edit.
Also, revert the changes to all the .pdf and .png files. We shouldn't
be touching them as they are pure-binary files.

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
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.