~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/releasing.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2010-10-15 07:36:59 UTC
  • mfrom: (5462.5.9 split-NEWS)
  • Revision ID: pqm@pqm.ubuntu.com-20101015073659-hes51hpjncxrezuq
(spiv) Split NEWS into per-series release notes,
 now found in doc/en/release-notes (Andrew Bennetts)

Show diffs side-by-side

added added

removed removed

Lines of Context:
132
132
   
133
133
       version_info = (x, y, z, 'dev', 0)
134
134
   
135
 
#. Add a new section at the top of ``NEWS`` about the new release,
136
 
   including its version number and the headings from
137
 
   ``NEWS-template.txt``.
 
135
#. If you made a new series, then start a new release-notes file::
 
136
 
 
137
       cd doc/en/release-notes
 
138
       cp series-template.txt bzr-x.y.txt  # e.g. bzr-2.3.txt
 
139
       bzr add bzr-x.y.txt
 
140
 
 
141
#. Add a new section at the top of the current release notes (in
 
142
   ``doc/en/release-notes``) about the new release, including its version
 
143
   number and the headings from ``release-template.txt``.
138
144
 
139
145
#. Update the "What's New" documents in ``doc/en/whats-new``.
140
146
 
173
179
 
174
180
       version_info = (2, 1, 2, 'final', 0)
175
181
 
176
 
#. Update the ``./NEWS`` section for this release.
 
182
#. Update the ``./doc/en/release-notes/`` section for this release.
177
183
 
178
184
   Fill out the date and a description of the release under the existing
179
 
   header. If there isn't one, follow the above for using the NEWS
180
 
   template.
 
185
   header. If there isn't one, follow the instructions above for using the
 
186
   ``release-template.txt`` file.
181
187
 
182
188
   See *2.1.1* or similar for an example of what this looks like.
183
189
 
184
190
#. Add a summary of the release into the "What's New" document.
185
191
 
186
 
#. To check that all bugs mentioned in ``./NEWS`` are actually marked as
187
 
   closed in Launchpad, you can run ``tools/check-newsbugs.py``::
 
192
#. To check that all bugs mentioned in the release notes are actually
 
193
   marked as closed in Launchpad, you can run
 
194
   ``tools/check-newsbugs.py``::
188
195
 
189
 
     ./tools/check-newsbugs.py NEWS
 
196
     ./tools/check-newsbugs.py doc/en/release-notes/bzr-x.y.txt
190
197
 
191
198
   (But note there will be many false positives, and this script may be
192
199
   flaky <https://bugs.edge.launchpad.net/bzr/+bug/354985>.  Don't let
370
377
      https://launchpad.net/bzr/2.x/2.x/ as a source tarball; packages
371
378
      for various systems will be available soon.
372
379
 
373
 
      <<NEWS section from this release back to the last major release>>
 
380
      <<release notes from this release back to the last major release>>
374
381
 
375
382
   Feel free to tweak this to your taste.
376
383
 
404
411
Merging the released code back to trunk
405
412
---------------------------------------
406
413
 
407
 
The rule is to keep ``NEWS`` sections sorted by date. You'll need to
408
 
review the merge and make sure that that is respected.
 
414
Merge the release branch back into the trunk.  The
 
415
``doc/en/release-notes`` changes should be merged into the right place
 
416
because each release series has its own release-notes file, but
 
417
double-check.
409
418
 
410
 
Merge the release branch back into the trunk.  Check that changes in NEWS
411
 
were merged into the right sections.  If it's not already done, advance
412
 
the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
413
 
back into pqm for bzr.dev.
 
419
If it's not already done, advance the version number in ``bzr`` and
 
420
``bzrlib/__init__.py``.  Submit this back into pqm for bzr.dev.
414
421
 
415
422
As soon as you change the version number in trunk, make sure you have
416
423
created the corresponding milestone to ensure the continuity in bug