Rev 6475: Update releasing instructions including more details about doc.bazaar.canonical.com when doing the first stable release in a new series. in file:///home/vila/src/bzr/releases/work/
Vincent Ladeuil
v.ladeuil+lp at free.fr
Thu Mar 8 12:32:03 UTC 2012
At file:///home/vila/src/bzr/releases/work/
------------------------------------------------------------
revno: 6475
revision-id: v.ladeuil+lp at free.fr-20120308123203-d0fq35mixvjqaf9s
parent: pqm at pqm.ubuntu.com-20120223193907-11erj8xxjmrchawp
committer: Vincent Ladeuil <v.ladeuil+lp at free.fr>
branch nick: work
timestamp: Thu 2012-03-08 13:32:03 +0100
message:
Update releasing instructions including more details about doc.bazaar.canonical.com when doing the first stable release in a new series.
-------------- next part --------------
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt 2012-01-18 10:29:50 +0000
+++ b/doc/developers/releasing.txt 2012-03-08 12:32:03 +0000
@@ -207,8 +207,8 @@
found at <https://launchpad.net/bzr/+milestone/x.y.z>.
#. Merge into your branch all previous stable series fixes that haven't been
- merged yet. For example, if you're releasing 2.5.x, make sure the fixes
- on 2.4, 2.3, etc have already been merged up::
+ merged yet. For example, if you're releasing 2.6.x, make sure the fixes
+ on 2.5, 2.4, 2.3, etc have already been merged up::
bzr merge lp:bzr/2.4
@@ -225,30 +225,30 @@
For beta releases use::
- version_info = (2, 5, 0, 'beta', SERIAL)
-
- For instance 2.5b5::
-
- version_info = (2, 5, 0, 'beta', 5)
+ version_info = (2, 6, 0, 'beta', SERIAL)
+
+ For instance 2.6b1::
+
+ version_info = (2, 6, 0, 'beta', 1)
For stable releases use::
- version_info = (2, 5, 0, 'final', 0)
+ version_info = (2, 6, 0, 'final', 0)
#. Update the ``./doc/en/release-notes/`` section for this release.
Check that all news entries related to this release have been added in
- the right section. For example, if you're releasing 2.5b5, the following
- command should display a a single chuk diff for the 2.5b5 release::
+ the right section. For example, if you're releasing 2.6b1, the following
+ command should display a a single chuk diff for the 2.6b1 release::
- bzr diff -rbzr-2.5b4.. doc/en/release-notes/bzr-2.5.txt
+ bzr diff -rbzr-2.6b1.. doc/en/release-notes/bzr-2.6.txt
Fill out the date and a description of the release under the existing
header (the diff above will help you summarizing). If there isn't one,
follow the instructions above for using the ``release-template.txt`` file
and remind people that they should document their changes there ;)
- See *2.5b5* or similar for an example of what this looks like.
+ See *2.6b1* or similar for an example of what this looks like.
#. Add or check the summary of the release into the "What's New" document.
@@ -352,7 +352,7 @@
#. Tag the new release::
- bzr tag bzr-2.3.1
+ bzr tag bzr-2.6.0
#. Push those changes to a bzr branch that is public and accessible on the
Internet. PQM will pull from this branch when it attempts to merge your
@@ -360,7 +360,7 @@
release branch::
bzr push
- bzr pqm-submit -m "(vila) Release 2.3.1 (Vincent Ladeuil)"
+ bzr pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
Note that ``bzr push`` should mention updating one tag (which you just
created). If it doesn't, double-check that you created (and pushed) this
@@ -517,7 +517,7 @@
control the process as tightly so guessing the date is not appropriate.
For the final beta release include in your announcement a notice of
- API and translation freezes nothing that public methods should not
+ API and translation freezes noting that public methods should not
be removed or changed and strings should not be added or changed.
#. Pause for a few days.
@@ -527,7 +527,7 @@
----------------------
There is normally a delay of a few days after the source freeze to allow
-for binaries to be built on various platforms. Once they have been built,
+for binaries to be built for various platforms. Once they have been built,
we have a releasable product. The next step is to make it generally
available to the world.
@@ -538,9 +538,17 @@
pushed to this branch are refreshed by a cron job on escudero.)
#. Check that the documentation for this release is available in
- <http://doc.bazaar.canonical.com>. It should be automatically build when the
- branch is created, by a cron script ``update-bzr-docs`` on
- ``escudero``.
+ <http://doc.bazaar.canonical.com>. It should be automatically build when
+ the branch is created, by a cron script ``update-bzr-docs`` on
+ ``escudero``. When the first release is created in a new series, a branch
+ needs to be created on escudero::
+
+ ssh escudero.canonical.com
+ sudo -u bzr-web -s
+ cd /srv/doc.bazaar.canonical.com/
+ bzr branch http://bazaar.launchpad.net/~bzr-pqm/bzr/2.5 bzr.2.5
+
+ And the ``update-bzr-docs`` needs to refer to it.
Announcing the release
@@ -615,10 +623,6 @@
series, create these links again. Check all links when doing other
kinds of release.
- * Set direct download: When releasing a new stable release, this should
- point to the corresponding launchpad page:
- <https://launchpad.net/bzr/x.y/x.y.z/>
-
#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should
be done for the stable and beta releases.
More information about the bazaar-commits
mailing list