/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Michael Hudson
  • Date: 2009-11-26 04:01:58 UTC
  • mto: This revision was merged to the branch mainline in revision 4830.
  • Revision ID: michael.hudson@canonical.com-20091126040158-3q6ukjpb38tlmxr9
test and fix

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.
55
55
   ``bzrlib/__init__.py`` file. Make sure there is always a corresponding
56
56
   milestone when you change that version number.
57
57
 
58
 
#. Add a new section at the top of ``NEWS`` about the new release,
59
 
   including its version number and the headings from
60
 
   ``NEWS-template.txt``.
61
 
 
62
58
#. Send mail to the list with the key dates, who will be the release
63
59
   manager, and the main themes or targeted bugs.  Ask people to nominate
64
60
   objectives, or point out any high-risk things that are best done early,
65
61
   or that interact with other changes. This is called the metronome mail
66
62
   and is described in `Development cycles <cycle.html>`_.
67
63
 
68
 
#. 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 
69
65
   release in a series, otherwise you should already have a branch.) ::
70
66
 
71
67
     bzr branch trunk prepare-1.14
108
104
 
109
105
#. Add the date and release number to ``./NEWS``
110
106
 
111
 
   Depending on whether you're doing a beta or a bugfix release, you'll
112
 
   have to create a NEWS section for your release in the right
113
 
   place. Most of the time, the new section is at the top of the file
114
 
   (look what have been done for the various 2.0x and 2.1.0bx releases).
115
 
   The rule is to keep the sections sorted by date. You'll need to be
116
 
   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
  
117
113
 
118
114
#. To check that all bugs mentioned in ``./NEWS`` are actually marked as
119
115
   closed in Launchpad, you can run ``tools/check-newsbugs.py``::
127
123
#. Summarize into one or two paragraphs what's new in this release.
128
124
 
129
125
#. Commit these changes to the release branch, using a command like::
130
 
 
131
 
     bzr commit -m "Release 1.14."
132
 
 
 
126
    
 
127
     bzr commit -m "Release 1.14." 
 
128
   
133
129
   The diff before you commit will be something like::
134
130
 
135
131
     === modified file 'NEWS'
136
132
     --- NEWS        2008-09-17 23:09:18 +0000
137
133
     +++ NEWS        2008-09-23 16:14:54 +0000
138
134
     @@ -4,6 +4,23 @@
139
 
 
 
135
     
140
136
      .. contents::
141
 
 
 
137
     
142
138
     +bzr 1.7 2008-09-23
143
139
     +------------------
144
140
     +
151
147
     +
152
148
      bzr 1.7rc2 2008-09-17
153
149
      ---------------------
154
 
 
155
 
 
 
150
     
 
151
     
156
152
     === modified file 'bzrlib/__init__.py'
157
153
     --- bzrlib/__init__.py  2008-09-16 21:39:28 +0000
158
154
     +++ bzrlib/__init__.py  2008-09-23 16:14:54 +0000
159
155
     @@ -41,7 +41,7 @@
160
156
      # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
161
157
      # releaselevel of 'dev' for unreleased under-development code.
162
 
 
 
158
     
163
159
     -version_info = (1, 7, 0, 'candidate', 2)
164
160
     +version_info = (1, 7, 0, 'final', 0)
165
 
 
166
 
 
 
161
     
 
162
     
167
163
      # API compatibility version: bzrlib is currently API compatible with 1.7.
168
 
 
 
164
      
169
165
#. Tag the new release::
170
166
 
171
167
     bzr tag bzr-1.14
174
170
   the Internet. PQM will pull from this repository when it attempts to merge
175
171
   your changes. Then submit those changes to PQM for merge into the
176
172
   appropriate release branch::
177
 
 
 
173
 
178
174
     bzr push
179
175
     bzr pqm-submit -m "(mbp) prepare 1.14"
180
176
 
185
181
-------------------------
186
182
 
187
183
#. Change into the source directory and run ::
188
 
 
 
184
  
189
185
     make dist
190
186
 
191
187
#. Now we'll try expanding this tarball and running the test suite
192
188
   to check for packaging problems::
193
 
 
 
189
 
194
190
     make check-dist-tarball
195
191
 
196
192
   You may encounter failures while running the test suite caused
263
259
   ``bazaar-announce`` list too.
264
260
 
265
261
   For final releases, it should also be cc'd to ``info-gnu@gnu.org``,
266
 
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.
 
262
   ``python-announce-list@python.org``, ``bug-directory@gnu.org``.  
267
263
 
268
264
   In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,
269
265
   so that people who reply to the announcement don't spam other lists.
270
266
 
271
267
   The announce mail will look something like this::
272
 
 
 
268
   
273
269
      Subject: bzr x.yy released!
274
 
 
 
270
      
275
271
      <<Summary paragraph from news>>
276
 
 
277
 
      The Bazaar team is happy to announce availability of a new
 
272
     
 
273
      The Bazaar team is happy to announce availability of a new 
278
274
      release of the bzr adaptive version control system.
279
275
      Bazaar is part of the GNU system <http://gnu.org/>.
280
 
 
 
276
     
281
277
      Thanks to everyone who contributed patches, suggestions, and
282
278
      feedback.
283
 
 
284
 
      Bazaar is now available for download from
285
 
      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 
286
282
      for various systems will be available soon.
287
 
 
 
283
      
288
284
      <<NEWS section from this release back to the last major release>>
289
285
 
290
286
   Feel free to tweak this to your taste.
295
291
   ensuring the new topic text keeps the project name, web site link, etc.
296
292
 
297
293
#. Announce on http://freshmeat.net/projects/bzr/
298
 
 
 
294
   
299
295
   This should be done for beta releases, release candidates and final
300
296
   releases. If you do not have a Freshmeat account yet, ask one of the
301
297
   existing admins.