Rev 3409: (mbp) split out and update release process docs in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

Canonical.com Patch Queue Manager pqm at pqm.ubuntu.com
Wed May 7 07:06:12 BST 2008


At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 3409
revision-id:pqm at pqm.ubuntu.com-20080507060601-0lucvc8utjxoi9tr
parent: pqm at pqm.ubuntu.com-20080506114010-jwclr2qtiekvawjg
parent: mbp at sourcefrog.net-20080507044610-thcasb9ic2ay2yup
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Wed 2008-05-07 07:06:01 +0100
message:
  (mbp) split out and update release process docs
added:
  doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
modified:
  doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
  doc/developers/index.txt       index.txt-20070508041241-qznziunkg0nffhiw-1
    ------------------------------------------------------------
    revno: 3408.1.1
    revision-id:mbp at sourcefrog.net-20080507044610-thcasb9ic2ay2yup
    parent: pqm at pqm.ubuntu.com-20080506114010-jwclr2qtiekvawjg
    parent: mbp at sourcefrog.net-20080502023218-d9n8p2mvrfqg6wyx
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Wed 2008-05-07 14:46:10 +1000
    message:
      Merge updated release process docs, plus tweaks from igc
    added:
      doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
    modified:
      doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
      doc/developers/index.txt       index.txt-20070508041241-qznziunkg0nffhiw-1
    ------------------------------------------------------------
    revno: 3383.2.6
    revision-id:mbp at sourcefrog.net-20080502023218-d9n8p2mvrfqg6wyx
    parent: mbp at sourcefrog.net-20080502023114-y2gcg3w3jc770j9m
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Fri 2008-05-02 12:32:18 +1000
    message:
      doc tone moderation
    modified:
      doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
    ------------------------------------------------------------
    revno: 3383.2.5
    revision-id:mbp at sourcefrog.net-20080502023114-y2gcg3w3jc770j9m
    parent: mbp at sourcefrog.net-20080502021439-232dh9bjyq3mtoad
    parent: pqm at pqm.ubuntu.com-20080501153825-fbc1be2c4g22idz8
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Fri 2008-05-02 12:31:14 +1000
    message:
      merge trunk
    added:
      bzrlib/tests/branch_implementations/test_check.py test_check.py-20080429151303-1sbfclxhddpz0tnj-1
      bzrlib/tests/branch_implementations/test_reconcile.py test_reconcile.py-20080429161555-qlmccuyeyt6pvho7-1
      bzrlib/tests/interrepository_implementations/test_fetch.py test_fetch.py-20080425213627-j60cjh782ufm83ry-1
    modified:
      Makefile                       Makefile-20050805140406-d96e3498bb61c5bb
      NEWS                           NEWS-20050323055033-4e00b5db738777ff
      bzr                            bzr.py-20050313053754-5485f144c7006fa6
      bzrlib/__init__.py             __init__.py-20050309040759-33e65acf91bbcd5d
      bzrlib/branch.py               branch.py-20050309040759-e4baf4e0d046576e
      bzrlib/builtins.py             builtins.py-20050830033751-fc01482b9ca23183
      bzrlib/bundle/bundle_data.py   read_changeset.py-20050619171944-c0d95aa685537640
      bzrlib/bundle/serializer/v4.py v10.py-20070611062757-5ggj7k18s9dej0fr-1
      bzrlib/fetch.py                fetch.py-20050818234941-26fea6105696365d
      bzrlib/hooks.py                hooks.py-20070325015548-ix4np2q0kd8452au-1
      bzrlib/knit.py                 knit.py-20051212171256-f056ac8f0fbe1bd9
      bzrlib/log.py                  log.py-20050505065812-c40ce11702fe5fb1
      bzrlib/mutabletree.py          mutabletree.py-20060906023413-4wlkalbdpsxi2r4y-2
      bzrlib/reconcile.py            reweave_inventory.py-20051108164726-1e5e0934febac06e
      bzrlib/remote.py               remote.py-20060720103555-yeeg2x51vn0rbtdp-1
      bzrlib/repository.py           rev_storage.py-20051111201905-119e9401e46257e3
      bzrlib/revisiontree.py         revisiontree.py-20060724012533-bg8xyryhxd0o0i0h-1
      bzrlib/smart/server.py         server.py-20061110062051-chzu10y32vx8gvur-1
      bzrlib/status.py               status.py-20050505062338-431bfa63ec9b19e6
      bzrlib/store/revision/knit.py  knit.py-20060303020652-de5fa299e941a3c7
      bzrlib/symbol_versioning.py    symbol_versioning.py-20060105104851-9ecf8af605d15a80
      bzrlib/tests/__init__.py       selftest.py-20050531073622-8d0e3c8845c97a64
      bzrlib/tests/blackbox/test_hooks.py test_hooks.py-20080308163236-xljgf9j41hik1x21-1
      bzrlib/tests/blackbox/test_reconcile.py test_fix.py-20060223013051-9a188e15a5ee9451
      bzrlib/tests/blackbox/test_version.py test_version.py-20070312060045-ol7th9z035r3im3d-1
      bzrlib/tests/branch_implementations/__init__.py __init__.py-20060123013057-b12a52c3f361daf4
      bzrlib/tests/branch_implementations/test_branch.py testbranch.py-20050711070244-121d632bc37d7253
      bzrlib/tests/branch_implementations/test_commit.py test_commit.py-20070206022134-117z1i5b644p63r0-1
      bzrlib/tests/branch_implementations/test_hooks.py test_hooks.py-20070129154855-blhpwxmvjs07waei-1
      bzrlib/tests/branch_implementations/test_pull.py test_pull.py-20060410103942-83c35b26657414fc
      bzrlib/tests/branch_implementations/test_push.py test_push.py-20070130153159-fhfap8uoifevg30j-1
      bzrlib/tests/branch_implementations/test_uncommit.py test_uncommit.py-20070205180410-ge7058d9138mvq3x-1
      bzrlib/tests/interrepository_implementations/__init__.py __init__.py-20060220054744-baf49a1f88f17b1a
      bzrlib/tests/interrepository_implementations/test_interrepository.py test_interrepository.py-20060220061411-1ec13fa99e5e3eee
      bzrlib/tests/repository_implementations/test_fetch.py test_fetch.py-20070814052151-5cxha9slx4c93uog-1
      bzrlib/tests/test_bundle.py    test.py-20050630184834-092aa401ab9f039c
      bzrlib/tests/test_fetch.py     testfetch.py-20050825090644-f73e07e7dfb1765a
      bzrlib/tests/test_hooks.py     test_hooks.py-20070628030849-89rtsbe5dmer5npz-1
      bzrlib/tests/test_knit.py      test_knit.py-20051212171302-95d4c00dd5f11f2b
      bzrlib/tests/test_reconcile.py test_reconcile.py-20060225054842-50aa618584a86f26
      bzrlib/tests/test_reconfigure.py test_reconfigure.py-20070908040425-6ykgo7escxhyrg9p-2
      bzrlib/tests/test_remote.py    test_remote.py-20060720103555-yeeg2x51vn0rbtdp-2
      bzrlib/tests/test_selftest.py  test_selftest.py-20051202044319-c110a115d8c0456a
      bzrlib/tests/test_smart.py     test_smart.py-20061122024551-ol0l0o0oofsu9b3t-2
      bzrlib/tests/test_smart_transport.py test_ssh_transport.py-20060608202016-c25gvf1ob7ypbus6-2
      bzrlib/tests/test_store.py     teststore.py-20050826022702-f6caadb647395769
      bzrlib/tests/transport_util.py transportutil.py-20070525113600-5v2igk89s8fensom-1
      bzrlib/tests/tree_implementations/__init__.py __init__.py-20060717075546-420s7b0bj9hzeowi-2
      bzrlib/tests/tree_implementations/test_inv.py test_inv.py-20070312023226-0cdvk5uwhutis9vg-1
      bzrlib/tests/tree_implementations/test_test_trees.py test_tree_trees.py-20060720091921-3nwi5h21lf06vf5p-1
      bzrlib/tests/workingtree_implementations/test_commit.py test_commit.py-20060421013633-1610ec2331c8190f
      bzrlib/transform.py            transform.py-20060105172343-dd99e54394d91687
      bzrlib/tree.py                 tree.py-20050309040759-9d5f2496be663e77
      bzrlib/workingtree.py          workingtree.py-20050511021032-29b6ec0a681e02e3
      bzrlib/workingtree_4.py        workingtree_4.py-20070208044105-5fgpc5j3ljlh5q6c-1
      doc/default.css                default.css-20060622101119-tgwtdci8z769bjb9-1
      doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
      doc/developers/network-protocol.txt networkprotocol.txt-20070903044232-woustorrjbmg5zol-1
      doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
      doc/en/user-guide/hooks.txt    hooks.txt-20070829200551-7nr6e5a1io6x78uf-1
    ------------------------------------------------------------
    revno: 3383.2.4
    revision-id:mbp at sourcefrog.net-20080502021439-232dh9bjyq3mtoad
    parent: mbp at sourcefrog.net-20080502020546-a7aldjqc74r23kju
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Fri 2008-05-02 12:14:39 +1000
    message:
      Trim from the release instructions things that are now automated or unnecessary
    modified:
      doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
    ------------------------------------------------------------
    revno: 3383.2.3
    revision-id:mbp at sourcefrog.net-20080502020546-a7aldjqc74r23kju
    parent: mbp at sourcefrog.net-20080428043103-wn29f8a8tzu6hnql
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Fri 2008-05-02 12:05:46 +1000
    message:
      Separate out and update the release manager instructions
    added:
      doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
    modified:
      doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
      doc/developers/index.txt       index.txt-20070508041241-qznziunkg0nffhiw-1
    ------------------------------------------------------------
    revno: 3383.2.2
    revision-id:mbp at sourcefrog.net-20080428043103-wn29f8a8tzu6hnql
    parent: mbp at sourcefrog.net-20080428042927-flca8fyy7nohv9g2
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Mon 2008-04-28 14:31:03 +1000
    message:
      Note about naming of rc versions
    modified:
      doc/developers/HACKING.txt     HACKING-20050805200004-2a5dc975d870f78c
    ------------------------------------------------------------
    revno: 3383.2.1
    revision-id:mbp at sourcefrog.net-20080428042927-flca8fyy7nohv9g2
    parent: pqm at pqm.ubuntu.com-20080428012318-g5zq9wl2flua3r2s
    committer: Martin Pool <mbp at sourcefrog.net>
    branch nick: doc
    timestamp: Mon 2008-04-28 14:29:27 +1000
    message:
      Point to all developer documentation doc/developer/index
    modified:
      doc/developers/index.txt       index.txt-20070508041241-qznziunkg0nffhiw-1
=== added file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	1970-01-01 00:00:00 +0000
+++ b/doc/developers/releasing.txt	2008-05-07 04:46:10 +0000
@@ -0,0 +1,327 @@
+Releasing Bazaar
+================
+
+This document describes the processes for making and announcing a Bazaar
+release, and managing the release process.
+
+See also: `Bazaar Developer Document Catalog <index.html>`_.
+
+
+.. contents::
+
+
+Starting a Release
+------------------
+
+To start a new release cycle:
+
+#. Send mail to the list with the key dates, who will be the release
+   manager, and the main themes or targetted bugs.  Ask people to nominate
+   objectives, or point out any high-risk things that are best done early,
+   or that interact with other changes.
+
+#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>.  There is one 
+   series for every *x.y* release.
+
+Weekly Status Updates
+---------------------
+
+TODO: Things to cover:
+
+* Early communication to downstream teams (e.g. Launchpad) about changes in dependencies.
+* Reminder re lifecycle and where we're up to right now
+* Summary of recent successes and pending work
+* Reminder re release objectives
+* Reminder re things needing attention, e.g. bug triage, reviews, testing of certain things, etc.
+
+
+Feature Freeze
+--------------
+
+TODO: Get material from http://bazaar-vcs.org/FeatureFreeze.
+
+
+
+Preparing the tree for release
+------------------------------
+
+.. Was previously at http://bazaar-vcs.org/ReleaseChecklist
+
+.. TODO: Still needs more clarity on what's in a RC versus a final
+.. release?
+
+This is the procedure for making a new bzr release:
+
+#. If the release is the first candidate, make a new branch in PQM. 
+   (Contact Robert Collins for this step).
+
+   Register the branch at https://launchpad.net/products/bzr/+addbranch
+
+#. Run the automatic test suite and any non-automated tests.  (For example, try a download over http; these should eventually be scripted though not automatically run.). Try to have all optional dependencies installed so that there are no tests skipped. Also make sure that you have the c extensions compiled (``make`` or ``python setup.py build_ext -i``).
+
+#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``
+
+#. Add the date and release number to ``./NEWS``.
+
+#. Commit these changes to the release branch, using a command like::
+    
+     bzr commit -m "(jam) Release 0.12rc1." 
+   
+   The diff before you commit will be something like::
+
+       === modified file 'NEWS'
+       --- NEWS        2006-10-23 13:11:17 +0000
+       +++ NEWS        2006-10-23 22:50:50 +0000
+       @@ -1,4 +1,4 @@
+       -IN DEVELOPMENT
+       +bzr 0.12rc1  2006-10-23
+
+          IMPROVEMENTS:
+
+
+       === modified file 'bzrlib/__init__.py'
+       --- bzrlib/__init__.py  2006-10-16 01:47:43 +0000
+       +++ bzrlib/__init__.py  2006-10-23 22:49:46 +0000
+       @@ -35,7 +35,7 @@
+        # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
+        # releaselevel of 'dev' for unreleased under-development code.
+
+       -version_info = (0, 12, 0, 'dev', 0)
+       +version_info = (0, 12, 0, 'candidate', 1)
+
+        if version_info[3] == 'final':
+            version_string = '%d.%d.%d' % version_info[:3]
+
+#. Submit those changes to PQM for merge into the appropriate release
+   branch.
+
+#. When PQM succeeds, pull down the master release branch.
+
+Making the source tarball
+-------------------------
+
+#. Change into the source directory and run
+  
+     make dist
+
+#. Unpack the tarball into a temporary directory and run ``make check`` in
+   that directory, to check for packaging problems.
+
+
+Publishing the release
+----------------------
+
+Now you have the releasable product.  The next step is making it
+available to the world.
+
+#. In <https://launchpad.net/bzr/> click the "Release series" for this
+   series, to take you to e.g. <https://launchpad.net/bzr/1.1>.  Then
+   click "Register a release", and add information about this release.
+
+#. Within that release, upload the source tarball and the GPG signature.
+
+#. Link from http://bazaar-vcs.org/Download to the tarball and signature.
+
+#. Update http://doc.bazaar-vcs.org/ to have a directory of documentation
+   for this release.  (Controlled by the ``update-bzr-docs`` script on
+   escudero, and also update the ``latest`` symlink in
+   ``/srv/bazaar.canonical.com/doc/``.)
+
+#. Announce on the `Bazaar home page`__
+   
+ __ http://bazaar-vcs.org/
+
+
+Announcing the release
+----------------------
+
+Now that the release is publicly available, tell people about it.
+
+#. Announce to ``bazaar-announce`` and ``bazaar`` mailing lists. 
+   The announce mail will look something like this:
+   
+    | Subject: bzr 0.11 release candidate 1
+    | 
+    | INTRO HERE. Mention the release number and date, and why the release. (i.e. release candidate for testing, final release of a version, backport/bugfix etc).
+    | 
+    | Tarballs:
+    | http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz
+    | and GPG signature:
+    | http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz.sig
+    | 
+    | DESCRIBE-CHANGES-IN-OVERVIEW-HERE
+    | 
+    | DESCRIBE-when the next release will be (if there is another - i.e. this is a release candidate)
+    | 
+    | Many thanks to all the contributors to this release! I've included the
+    | contents of NEWS for VERSION below:
+
+   To generate the data from NEWS, just copy and paste the relevant news section and clean it up as appropriate. The main clean-up task is to confirm that all major changes are indeed covered. This can be done by running ``bzr log`` back to the point when the branch was opened and cross checking the changes against the NEWS entries.
+
+   (RC announcements should remind plugin maintainers to update their plugins.)
+
+     * For point releases (i.e. a release candidate, or an incremental fix
+       to a released version) take everything in the relevant NEWS section.  For
+       example, for 0.11rc2 take everything in NEWS from the bzr 0.11rc2 line to the bzr 0.11rc1 line further down.
+
+     * For major releases (i.e. 0.11, 0.12 etc), take all the combined NEWS sections from within that version: for 0.11 take all of the 0.11 specific section, plus 0.11rc2, plus 0.11rc1 etc.
+
+#. Update the IRC channel topic. Use the ``/topic`` command to do this, ensuring the new topic text keeps the project name, web site link, etc.
+
+#. Announce on http://freshmeat.net/projects/bzr/
+   
+   This should be done for both release candidates and final releases. If you do not have a Freshmeat account yet, ask one of the existing admins.
+
+#. Update http://en.wikipedia.org/wiki/Bzr -- this should be done for final releases but not Release Candidates.
+
+#. Package maintainers should update packages when they see the
+   announcement.
+
+#. Blog about it.
+
+#. Post to http://mail.python.org/mailman/listinfo/python-announce-list for major releases
+
+#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
+   done by running ::
+
+       python setup.py register
+
+   Remember to check the results afterwards.
+
+
+Merging the released code back to trunk
+---------------------------------------
+
+Merge the release branch back into the trunk.  Check that changes in NEWS
+were merged into the right sections.  If it's not already done, advance
+the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
+back into pqm for bzr.dev.
+
+
+Updating the PPA for a new release
+----------------------------------
+
+We build Ubuntu ``.deb`` packages for Bazaar as an important part of the release
+process.  These packages are hosted in a `Personal Package Archive (PPA)`__ on
+Launchpad, at <https://launchpad.net/~bzr/+archive>.
+
+  __ https://help.launchpad.net/PPAQuickStart
+
+We build packages for every supported Ubuntu release
+<https://wiki.ubuntu.com/Releases>.  Packages need no longer be updated
+when the release passes end-of-life because all users should
+updated by then.
+
+The ``debian/`` directory containing the packaging information is kept in
+branches on Launchpad, named like 
+<https://code.launchpad.net/~bzr/bzrtools/packaging-dapper>.
+
+Preconditions for building these packages:
+  
+* You must have a Launchpad account and be a member of the `~bzr`__ team
+  
+__ https://edge.launchpad.net/~bzr/+members>
+
+* You must have a GPG key registered to your Launchpad account.
+
+* Configure ``dput`` to upload to our PPA with this section in your
+  ``~/.dput.cf``::
+
+    [bzr-ppa]
+    fqdn = ppa.launchpad.net
+    method = ftp
+    incoming = ~bzr/ubuntu
+    login = anonymous
+    allow_unsigned_uploads = 0
+
+* You need a Ubuntu (or probably Debian) machine, and ::
+
+    sudo apt-get install build-essential devscripts dput
+
+Here is the process; there are some steps which should be automated in
+future:
+
+#. You will need a working directory for each supported release, such as
+   ``~/bzr/Packaging/dapper``
+
+#. Download the official tarball of the release to e.g. ``~/bzr/Releases``
+
+#. Copy the original tarball into your per-disto directory, then untar it 
+   and if necessary rename it::
+
+     cp -l ~/bzr/Releases/bzrtools-1.3.0.tar.gz bzrtools_1.3.0.orig.tar.gz
+     tar xfvz bzrtools_1.3.0.orig.tar.gz
+     mv bzrtools bzrtools-1.3.0
+
+#. Change into that directory and check out the packaging branch::
+
+     cd bzrtools
+     bzr checkout \
+       bzr+ssh://bazaar.launchpad.net/~bzr/bzrtools/packaging-dapper \
+       debian
+
+#. For Bazaar plugins, change the ``debian/control`` file to express a
+   dependency on the correct version of ``bzr``.
+
+   For bzrtools this is typically::
+
+      Build-Depends-Indep: bzr (>= 1.3~), rsync
+      Depends: ${python:Depends}, bzr (>= 1.3~), bzr (<< 1.4~), patch
+
+#. Make a new ``debian/changelog`` entry for the new release,
+   either by using ``dch`` or just editing the file::
+
+     dch -v '1.3.0-1~bazaar1~dapper1' -D dapper
+
+   dch will default to the distro you're working in and this isn't checked
+   against the version number (which is just our conversion), so make sure 
+   to specify it.
+
+   **Caution:** Release candidates must insert a tilde to make them sort before the
+   final release, like this: ``bzr-1.4~rc2-1~bazaar1~dapper1``.
+
+   Make sure you have the correct email address for yourself, version
+   number, and distribution.  It should look something like this::
+
+       bzrtools (1.3.0-1~bazaar1~dapper1) dapper; urgency=low
+     
+        * New upstream release.
+     
+       -- John Sample <sample at example.com>  Mon, 31 Mar 2008 12:36:27 +1100
+
+   If you need to upload the package again to fix a problem, normally you
+   should increment the last number in the version number, following the
+   distro name.  Make sure not to omit the initial ``-1``, and make sure
+   that the distro name in the version is consistent with the target name
+   outside the parenthesis.
+
+#. Commit these changes into the packaging branch::
+
+     bzr ci -m '1.3.0-1~bazaar1~dapper1: New upstream release.' debian
+
+#. Build a source package::
+
+     debuild -S -sa -i
+
+   This will create a ``.changes`` file in the per-distro directory,
+   and should invoke gpg to sign it with your key.
+   Check that file is reasonable: it should be uploading to the intended
+   distribution, have a .orig file included, and the right version number.
+
+#. Upload into the PPA::
+
+     dput bzr-ppa ../bzrtools__1.3.0-1\~bazaar1\~dapper1_source.changes
+
+   Don't forget the ``bzr-ppa`` component or dput will try to upload into
+   the main archive by default.  You can disable this by adding this
+   section to your ``.dput.cf``::
+
+     [ubuntu]
+     fqdn = SPECIFY.A.PPA.NAME
+
+#. You should soon get an "upload accepted" mail from Launchpad, which
+   means that your package is waiting to be built.  You can then track its
+   progress in <https://launchpad.net/~bzr/+archive> and
+   <https://launchpad.net/~bzr/+archive/+builds>.
+
+

=== modified file 'doc/developers/HACKING.txt'
--- a/doc/developers/HACKING.txt	2008-04-28 03:52:09 +0000
+++ b/doc/developers/HACKING.txt	2008-05-02 02:32:18 +0000
@@ -1755,381 +1755,7 @@
 .. note::
   As well as prioritizing bugs and nominating them against a
   target milestone, Launchpad lets core developers offer to mentor others in
-  fixing them. Nice.
-
-
-Managing a Release
-==================
-
-Starting a Release
-------------------
-
-To start a new release cycle:
-
-#. Send mail to the list with the key dates, who will be the release
-   manager, and the main themes or targetted bugs.  Ask people to nominate
-   objectives, or point out an high-risk things that are best done early,
-   or that interact with other changes.
-
-#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>.  There is one 
-   series for every *x.y* release.
-
-Weekly Status Updates
----------------------
-
-TODO: Things to cover:
-
-* Early communication to downstream teams (e.g. Launchpad) about changes in dependencies.
-* Reminder re lifecycle and where we're up to right now
-* Summary of recent successes and pending work
-* Reminder re release objectives
-* Reminder re things needing attention, e.g. bug triage, reviews, testing of certain things, etc.
-
-
-Feature Freeze
---------------
-
-TODO: Get material from http://bazaar-vcs.org/FeatureFreeze.
-
-
-
-Making a Release or Release Candidate
--------------------------------------
-
-.. Was previously at http://bazaar-vcs.org/ReleaseChecklist
-
-.. TODO: Still needs more clarity on what's in a RC versus a final
-.. release?
-
-.. TODO: Too much of this is manual but could be automated...
-
-This is the procedure for making a new bzr release:
-
-#. If the release is the first candidate, make a new branch in PQM. (Contact RobertCollins for this step).
-
-   Register the branch at https://launchpad.net/products/bzr/+addbranch
-
-#. Run the automatic test suite and any non-automated tests.  (For example, try a download over http; these should eventually be scripted though not automatically run.). Try to have all optional dependencies installed so that there are no tests skipped. Also make sure that you have the c extensions compiled (``make`` or ``python setup.py build_ext -i``).
-
-#. In the release branch, update  ``version_info`` in ``./bzrlib/__init__.py``
-
-#. Add the date and release number to ``./NEWS``.
-
-#. Update the release number in the README. (It's not there as of 0.15, but please check).
-
-#. Commit these changes to the release branch, using a command like::
-    
-     bzr commit -m "(jam) Release 0.12rc1." 
-   
-   The diff before you commit will be something like::
-
-       === modified file 'NEWS'
-       --- NEWS        2006-10-23 13:11:17 +0000
-       +++ NEWS        2006-10-23 22:50:50 +0000
-       @@ -1,4 +1,4 @@
-       -IN DEVELOPMENT
-       +bzr 0.12rc1  2006-10-23
-
-          IMPROVEMENTS:
-
-
-       === modified file 'bzrlib/__init__.py'
-       --- bzrlib/__init__.py  2006-10-16 01:47:43 +0000
-       +++ bzrlib/__init__.py  2006-10-23 22:49:46 +0000
-       @@ -35,7 +35,7 @@
-        # Python version 2.0 is (2, 0, 0, 'final', 0)."  Additionally we use a
-        # releaselevel of 'dev' for unreleased under-development code.
-
-       -version_info = (0, 12, 0, 'dev', 0)
-       +version_info = (0, 12, 0, 'candidate', 1)
-
-        if version_info[3] == 'final':
-            version_string = '%d.%d.%d' % version_info[:3]
-
-#. Submit those changes to PQM for merge into the appropriate release
-   branch.
-
-#. When PQM succeeds, pull down the master release branch.
-
-#. Run ``make dist`` from a clean copy of the release branch; this will
-   produce a tarball and prompt you to sign it.
-
-#. Unpack the tarball into a temporary directory and run ``make check`` in
-   that directory.
-
-#. Run ``setup.py install`` --root=prefix to do a test install into your system directory, home directory, or some other prefix.  Check the install worked and that the installed version is usable. (run the bzr script from the installed path with PYTHONPATH set to the site-packages directory it created). i.e. ::
-
-    python setup.py install --root=installed
-    PYTHONPATH=installed/usr/lib/python2.4/site-packages installed/usr/bin/bzr
-
-
-Publishing the release
-----------------------
-
-Now you have the releasable product.  The next step is making it
-available to the world.
-
-#. In <https://launchpad.net/bzr/> click the "Release series" for this
-   series, to take you to e.g. <https://launchpad.net/bzr/1.1>.  Then
-   click "Register a release", and add information about this release.
-
-#. Within that release, upload the source tarball and the GPG signature.
-
-   (These used to also be uploaded to 
-   <sftp://escudero.ubuntu.com/srv/bazaar.canonical.com/www/releases/src>
-   but that's not accessible to all developers, and gets some mime types
-   wrong...  This upload can still be done with ``make
-   dist-upload-escudero``.)
-
-#. Link from http://bazaar-vcs.org/Download to the tarball and signature.
-
-#. Update http://doc.bazaar-vcs.org/ to have a directory of documentation
-   for this release.  (Controlled by the ``update-bzr-docs`` script on
-   escudero, and also update the ``latest`` symlink in
-   ``/srv/bazaar.canonical.com/doc/``.)
-
-#. Announce on the `Bazaar home page`__
-   
- __ http://bazaar-vcs.org/
-
-
-Announcing the release
-----------------------
-
-Now that the release is publicly available, tell people about it.
-
-#. Announce to ``bazaar-announce`` and ``bazaar`` mailing lists. 
-   The announce mail will look something like this:
-   
-    | Subject: bzr 0.11 release candidate 1
-    | 
-    | INTRO HERE. Mention the release number and date, and why the release. (i.e. release candidate for testing, final release of a version, backport/bugfix etc).
-    | 
-    | Tarballs:
-    | http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz
-    | and GPG signature:
-    | http://bazaar-vcs.org/releases/src/bzr-VERSION.tar.gz.sig
-    | 
-    | DESCRIBE-CHANGES-IN-OVERVIEW-HERE
-    | 
-    | DESCRIBE-when the next release will be (if there is another - i.e. this is a release candidate)
-    | 
-    | Many thanks to all the contributors to this release! I've included the
-    | contents of NEWS for VERSION below:
-
-   To generate the data from NEWS, just copy and paste the relevant news section and clean it up as appropriate. The main clean-up task is to confirm that all major changes are indeed covered. This can be done by running ``bzr log`` back to the point when the branch was opened and cross checking the changes against the NEWS entries.
-
-   (RC announcements should remind plugin maintainers to update their plugins.)
-
-     * For point releases (i.e. a release candidate, or an incremental fix to a released version) take everything in the relevant NEWS secion : for 0.11rc2 take everything in NEWS from the bzr 0.11rc2 line to the bzr 0.11rc1 line further down.
-
-     * For major releases (i.e. 0.11, 0.12 etc), take all the combined NEWS sections from within that version: for 0.11 take all of the 0.11 specific section, plus 0.11rc2, plus 0.11rc1 etc.
-
-#. Update the `news side menu`__ -- this currently requires downloading the file, editing it, deleting it, and uploading a replacement.
-
-   __ http://bazaar-vcs.org/site/menu?action=AttachFile&do=view&target=news.html
-
-#. Update the IRC channel topic. Use the ``/topic`` command to do this, ensuring the new topic text keeps the project name, web site link, etc.
-
-#. Announce on http://freshmeat.net/projects/bzr/
-   
-   This should be done for both release candidates and final releases. If you do not have a Freshmeat account yet, ask one of the existing admins.
-
-#. Update http://en.wikipedia.org/wiki/Bzr -- this should be done for final releases but not Release Candidates.
-
-#. Package maintainers should update packages when they see the
-   announcement.
-
-#. Blog about it.
-
-#. Post to http://mail.python.org/mailman/listinfo/python-announce-list for major releases
-
-#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best
-   done by running ::
-
-       python setup.py register
-
-   Remember to check the results afterwards.
-
-
-Merging the released code back to trunk
----------------------------------------
-
-Merge the release branch back into the trunk.  Check that changes in NEWS
-were merged into the right sections.  If it's not already done, advance
-the version number in ``bzr`` and ``bzrlib/__init__.py``.  Submit this
-back into pqm for bzr.dev.
-
-
-
-Making Win32 installers
------------------------
-
-**XXX:** This information is now probably obsolete, as Alexander uploads
-direct to Launchpad.  --mbp 20080116
-
-Alexander Belchenko has been very good about getting packaged installers compiled (see Win32ReleaseChecklist for details). He generally e-mails John Arbash Meinel when they are ready. This is just a brief checklist of what needs to be done.
-
-#. Download and verify the sha1 sums and gpg signatures. Frequently the sha1 files are in dos mode, and need to be converted to unix mode (strip off the trailing ``\r``) before they veryify correctly.
-
-#. Upload to the Launchpad page for this release.
-
-#. Upload to escudero (to the b.c.c/www/releases/win32 directory) using sftp, lftp or rsync
-
-#. Cat the contents of the .sha1 files into the SHA1SUM.
-
-#. Update the SHA1SUM and MD5SUM files using something like ``md5sum bzr-0.14.0.win32.exe >> MD5SUM``. Make sure you use append (>>) rather than overwrite (>).
-
-#. Verify once again that everything is correct with ``sha1sum -c SHA1SUM`` and ``md5sum -c MD5SUM``.
-
-#. Update ``.htaccess`` so that the 'bzr-latest.win32.exe' links point to the latest release. This is not done for candidate releases, only for final releases. (example: bzr-0.14.0, but not bzr-0.14.0rc1).
-
-#. Make sure these urls work as expected:
-
-   http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe
-
-   http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.5.exe.asc
-
-   http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe
-
-   http://bazaar-vcs.org/releases/win32/bzr-latest.win32-py2.4.exe.asc
-
-   http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe
-
-   http://bazaar-vcs.org/releases/win32/bzr-setup-latest.exe.asc
-   
-They should all try to download a file with the correct version number.
-
-#. Update http://bazaar-vcs.org/Download to indicate the newly available versions.
-
-#. Update http://bazaar-vcs.org/WindowsDownloads to have the correct version number as well as the correct sha1sum displayed.
-
-
-The Bazaar PPA archive
-----------------------
-
-We build Ubuntu ``.deb`` packages for Bazaar as an important part of the release
-process.  These packages are hosted in a `Personal Package Archive (PPA)`__ on
-Launchpad, at <https://launchpad.net/~bzr/+archive>.
-
-  __ https://help.launchpad.net/PPAQuickStart
-
-We build packages for every supported Ubuntu release
-<https://wiki.ubuntu.com/Releases>.  Packages need no longer be updated
-when the release passes end-of-life because all users should have then
-update.
-
-The ``debian/`` directory containing the packaging information is kept in
-branches on Launchpad, named like 
-<https://code.launchpad.net/~bzr/bzrtools/packaging-dapper>
-
-Updating the PPA for a new release
-----------------------------------
-
-Preconditions for building these packages:
-  
- * You must have a Launchpad account and be a member of the `~bzr`__ team
-   
- __ https://edge.launchpad.net/~bzr/+members>
-
- * You must have a GPG key registered to your Launchpad account.
-
- * Configure ``dput`` to upload to our PPA with this section in your
-   ``~/.dput.cf``::
-
-        [bzr-ppa]
-        fqdn = ppa.launchpad.net
-        method = ftp
-        incoming = ~bzr/ubuntu
-        login = anonymous
-        allow_unsigned_uploads = 0
-
- * You need a Ubuntu (or probably Debian) machine, and ::
-
-     sudo apt-get install build-essential devscripts dput
-
-Here is the process; there are some steps which should be automated in
-future:
-
-#. You will need a working directory for each supported release, such as
-   ``~/bzr/Packaging/dapper``
-
-#. Download the official tarball of the release to e.g. ``~/bzr/Releases``
-
-#. Copy the original tarball into your per-disto directory, then untar it 
-   and if necessary rename it::
-
-     cp -l ~/bzr/Releases/bzrtools-1.3.0.tar.gz bzrtools_1.3.0.orig.tar.gz
-     tar xfvz bzrtools_1.3.0.orig.tar.gz
-     mv bzrtools bzrtools-1.3.0
-
-#. Change into that directory and check out the packaging branch::
-
-     cd bzrtools
-     bzr checkout \
-       bzr+ssh://bazaar.launchpad.net/~bzr/bzrtools/packaging-dapper \
-       debian
-
-#. For Bazaar plugins, change the ``debian/control`` file to express a
-   dependency on the correct version of ``bzr``.
-
-   For bzrtools this is typically::
-
-      Build-Depends-Indep: bzr (>= 1.3~), rsync
-      Depends: ${python:Depends}, bzr (>= 1.3~), bzr (<< 1.4~), patch
-
-#. Make a new ``debian/changelog`` entry for the new release,
-   either by using ``dch`` or just editing the file::
-
-     dch -v '1.3.0-1~bazaar1~dapper1' -D dapper
-
-   dch will default to the distro you're working in and this isn't checked
-   against the version number (which is just our conversion).  So make
-   sure to specify it.
-
-   Make sure you have the correct email address for yourself, version
-   number, and distribution.  It should look something like this::
-
-     >  bzrtools (1.3.0-1~bazaar1~dapper1) dapper; urgency=low
-     >
-     >   * New upstream release.
-     >
-     >  -- John Sample <sample at example.com>  Mon, 31 Mar 2008 12:36:27 +1100
-
-   If you need to upload the package again to fix a problem, normally you
-   should increment the last number in the version number, following the
-   distro name.  Make sure not to omit the initial ``-1``, and make sure
-   that the distro name in the version is consistent with the target name
-   outside the parenthesis.
-
-#. Commit these changes into the packaging branch::
-
-     bzr ci -m '1.3.0-1~bazaar1~dapper1: New upstream release.' debian
-
-#. Build a source package::
-
-     debuild -S -sa -i
-
-   This will create a ``.changes`` file in the per-distro directory,
-   and should invoke gpg to sign it with your key.
-   Check that file is reasonable: it should be uploading to the intended
-   distribution, have a .orig file included, and the right version number.
-
-#. Upload into the PPA::
-
-     dput bzr-ppa ../bzrtools__1.3.0-1\~bazaar1\~dapper1_source.changes
-
-   Don't forget the ``bzr-ppa`` component or dput will try to upload into
-   the main archive by default.  You can disable this by adding this
-   section to your ``.dput.cf``::
-
-     [ubuntu]
-     fqdn = SPECIFY.A.PPA.NAME
-
-#. You should soon get an "upload accepted" mail from Launchpad, which
-   means that your package is waiting to be built.  You can then track its
-   progress in <https://launchpad.net/~bzr/+archive> and
-   <https://launchpad.net/~bzr/+archive/+builds>.
+  fixing them. 
 
 
 ..

=== modified file 'doc/developers/index.txt'
--- a/doc/developers/index.txt	2008-04-08 07:46:55 +0000
+++ b/doc/developers/index.txt	2008-05-02 02:05:46 +0000
@@ -2,12 +2,21 @@
 Bazaar Developer Document Catalog
 =================================
 
-See the `Main Document Catalog <../index.html>`_ for additional documents
-including the Bazaar Developer Guide and bzrlib API reference.
+Bazaar user documentation is in the 
+`Main Document Catalog <../index.html>`_.
+
+Overall developer documentation
+===============================
+
+* `Developer Guide <en/developer-guide/HACKING.html>`_
+* `bzrlib API reference <http://bazaar-vcs.org/BzrLib>`_
 
 Process
 =======
 
+* `Releasing Bazaar <releasing.html>`_ -- How to make a release of Bazaar,
+  and how to coordinate the monthly development cycle.
+
 * `Profiling notes <profiling.html>`_ |--| Instructions on how to profile 
   bzr code and visualize the results.
 




More information about the bazaar-commits mailing list