Merge lp:~vila/brz/prepare-3.0.0 into lp:brz

Proposed by Vincent Ladeuil
Status: Merged
Approved by: Vincent Ladeuil
Approved revision: no longer in the source branch.
Merge reported by: The Breezy Bot
Merged at revision: not available
Proposed branch: lp:~vila/brz/prepare-3.0.0
Merge into: lp:brz
Diff against target: 375 lines (+53/-130)
3 files modified
doc/developers/releasing.txt (+51/-128)
doc/en/_templates/index.html (+1/-1)
doc/en/index.txt (+1/-1)
To merge this branch: bzr merge lp:~vila/brz/prepare-3.0.0
Reviewer Review Type Date Requested Status
Jelmer Vernooij Approve
Review via email:

Commit message

Start preparing brz releases.

Description of the change

First pass on the doc/developers/releasing.txt to simplify breezy releases.

I haven't documented the alpha release process so we can discuss it first, a few things appeared while I was reviewing the bzr process:

- we should have defined a 3.0.0b1 milestone rather than using the 3.0.0 one
- we use breezy rather than brz for pypi project name (sounds ok to me but I haven't tested yet)
- we should think about releasing the doc somewhere that is not (the bzr setup has always been messy and probaly completely dead as we speak)
- Is there really a <email address hidden> list ?

For the alpha release I think we should:
- upload a tarball to lp
- upload a tarball to pypi
- mail <email address hidden>

To post a comment you must log in.
Revision history for this message
Jelmer Vernooij (jelmer) wrote :

There is indeed no packagers list yet, I think we just added up with a reference to that because of overzealous s/bzr/brz/ replacing. :)

I'd like to publish all the documentation on somewhere, since the docs on will be out of date.

Publishing the alpha to lp, pypi and mailing to the Bazaar list seems reasonable to me. Perhaps we can also add a post on the homepage?

review: Approve
lp:~vila/brz/prepare-3.0.0 updated
7110. By Jelmer Vernooij

Drop python3.flapping.

Merged from

7111. By Jelmer Vernooij

Drop the whitelist for Python 3 now that all tests are passing.

Merged from

7112. By Vincent Ladeuil

Start preparing brz releases.

Merged from

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'doc/developers/releasing.txt'
2--- doc/developers/releasing.txt 2017-11-11 12:51:45 +0000
3+++ doc/developers/releasing.txt 2018-09-14 09:41:35 +0000
4@@ -23,15 +23,8 @@
5 Preconditions
6 =============
8-#. PQM access rights (or you won't be able to land any change)
10-#. Download the pqm plugin and install it into your ``~/.bazaar/plugins``::
12- brz branch lp:brz-pqm ~/.bazaar/plugins/pqm
14-#. Alternatively, you can download and install ``lp:hydrazine`` (the main
15- difference is that hydrazine requires the branch to land to be hosted on
16- launchpad).
17+#. Be a member of (or you won't be able to land
18+ any change)
20 What do we release
21 ==================
22@@ -39,7 +32,7 @@
23 In this document, we're talking about source releases only, packages and
24 installers are built from this but we won't talk about them here.
26-Every release is part of a series, ``brz-2.4.1`` is part of series ``2.4``.
27+Every release is part of a series, ``brz-3.0.0`` is part of series ``3.0``.
29 We do two different kind of releases: the betas releases and the stable
30 releases for a given series.
31@@ -63,18 +56,7 @@
32 When do we relase ?
33 ===================
35-As of July 2011, we maintain four series (and one that is about to be EOLed).
36-Concurrently releasing them all at the same time makes it harder to shorten
37-the delay between the source availability and the package building longer
38-than necessary (we delay the official announcement until most of our users
39-can install the new release).
41-In order to continue to do time-based releases, we need to plan the
42-releases by series to minimize the collisions. In the end, it's the Release
43-Manager call to decide whether he prefers to do all releases at once
44-though, so the rules presented here are a conservative approach.
46-We want to respect the following rules:
47+As of September 2018, we maintain a single series: 3.0.
49 #. as much as possible releases should not disturb development, and
50 ongoing development should not disturb releases,
51@@ -103,12 +85,6 @@
52 Release Manager is free to ignore this (get in touch with packagers
53 though),
55-#. the series are aligned with Ubuntu releases for convenience since we
56- create a new series every 6 months. This means that we support the
57- stable series for 18 months. Note that we also propose the most recent
58- stable series via the stable PPA but that the SRU processs allow us to
59- reach a wider audience.
61 At the start of a series cycle
62 ==============================
64@@ -121,21 +97,21 @@
65 expected dates. Only the milestone associated to the next release in
66 this series should be left active to avoid clutter when targeting bugs.
68-#. If you made a new series, you will need to create a new pqm-controlled
69- branch for this release series. This branch will be used only from the
70- first non-beta release onwards. It needs to be created by a Canonical
71- sysadmin (ask the core devs for instructions or to do it for you).
72+#. If you made a new series, you will need to create a new branch for this
73+ release series. This branch will be used only from the first non-beta
74+ release onwards. It needs to be created by a
75+ member (ask the core devs for instructions or to do it for you).
77 #. Start a new release-notes file::
79 cd doc/en/release-notes
80- cp series-template.txt brz-x.y.txt # e.g. brz-2.3.txt
81- brz add brz-x.y.txt
82+ cp series-template.txt brz-x.y.txt # e.g. brz-3.1.txt
83+ brz add brz-3.1.txt
85 #. Start a new whats-new file::
87 cd doc/en/whats-new
88- cp template.txt brz-x.y.txt # e.g. brz-2.6.txt
89+ cp template.txt brz-x.y.txt # e.g. brz-3.1.txt
90 brz add brz-x.y.txt
92 #. Update ``doc/en/index.txt`` to point to the new whats-new file.
93@@ -162,20 +138,7 @@
94 Note that you will generally reuse the same branch for all releases in a
95 given series.
97-#. Configure pqm-submit for this branch, with a section like this (where
98- ``x.y`` is the series for your release). **Or use hydrazine for easier
99- setup** ``~/.bazaar/locations.conf``::
101- [/home/mbp/brz/x.y-dev]
102- pqm_email = Canonical PQM <>
103- submit_branch =
104- parent_branch =
105- public_branch =
106- submit_to =
107- smtp_server =
109- Please see <>
110- for more details on PQM
111+#. Add a landing job for the release branch at
113 #. Update the version number in the ``brz`` script, and the
114 ``breezy/`` file::
115@@ -193,7 +156,8 @@
116 <> allows you to toggle the
117 active flag.
119-#. Commit this and send it to PQM.
120+#. Commit this and make a proposal against the release branch. Self approve
121+ it (you're the release manager).
124 Doing a particular release
125@@ -208,17 +172,19 @@
126 found at <>.
128 #. Merge into your branch all previous stable series fixes that haven't been
129- merged yet. For example, if you're releasing 2.6.x, make sure the fixes
130- on 2.5, 2.4, 2.3, etc have already been merged up::
131+ merged yet. For example, if you're releasing 3.2.x, make sure the fixes
132+ on 3.1, 3.0 have already been merged up::
134- brz merge lp:brz/2.4
135+ brz merge lp:brz/3.1
137 and commit that merge in its own commit. This should happen only if the
138 devs landing changes in previous releases forgot to merge them up. Since
139 this can slow down the freeze, feel free to gently remind them about
140 their duties ;) If you feel unsafe resolving the conflicts or it's too
141 time consuming, contact the related devs and skip this merge.
144+ Alternatively, think about automating these merges.
146 #. In the release branch, update ``version_info`` in ``./breezy/``.
147 Make sure the corresponding milestone exists.
148 Double check that ./brz ``_script_version`` matches ``version_info``. Check
149@@ -226,30 +192,30 @@
151 For beta releases use::
153- version_info = (2, 6, 0, 'beta', SERIAL)
155- For instance 2.6b1::
157- version_info = (2, 6, 0, 'beta', 1)
158+ version_info = (3, 0, 0, 'beta', SERIAL)
160+ For instance 3.0b1::
162+ version_info = (3, 0, 0, 'beta', 1)
164 For stable releases use::
166- version_info = (2, 6, 0, 'final', 0)
167+ version_info = (3, 0, 0, 'final', 0)
169 #. Update the ``./doc/en/release-notes/`` section for this release.
171 Check that all news entries related to this release have been added in
172- the right section. For example, if you're releasing 2.6b2, the following
173- command should display a a single chuk diff for the 2.6b2 release::
174+ the right section. For example, if you're releasing 3.0b3, the following
175+ command should display a a single chuk diff for the 3.0b3 release::
177- brz diff -rbrz-2.6b2.. doc/en/release-notes/brz-2.6.txt
178+ brz diff -rbrz-3.0b2.. doc/en/release-notes/brz-3.0.txt
180 Fill out the date and a description of the release under the existing
181 header (the diff above will help you summarizing). If there isn't one,
182 follow the instructions above for using the ``release-template.txt`` file
183 and remind people that they should document their changes there ;)
185- See *2.6b1* or similar for an example of what this looks like.
186+ See *3.0b1* or similar for an example of what this looks like.
188 #. Add or check the summary of the release into the "What's New" document.
190@@ -362,26 +328,21 @@
192 #. Tag the new release::
194- brz tag brz-2.6.0
195+ brz tag brz-3.0.0
197-#. Push those changes to a brz branch that is public and accessible on the
198- Internet. PQM will pull from this branch when it attempts to merge your
199- changes. Then submit those changes to PQM for merge into the appropriate
200- release branch::
201+#. Push those changes to a brz branch and make a merge proposal::
203 brz push
204- brz pqm-submit -m "(vila) Release 2.6.0 (Vincent Ladeuil)"
206+ Use a commit message formatted like::
208+ (vila) Release 3.0.0 (Vincent Ladeuil)
210 Note that ``brz push`` should mention updating one tag (which you just
211 created). If it doesn't, double-check that you created (and pushed) this
212 tag.
214- Or with hydrazine::
216- brz lp-propose -m "Release 1.14" --approve lp:brz/1.14
217- feed-pqm brz
219-#. When PQM succeeds, pull down the master release branch.
220+#. Once the merge proposal has landed, pull down the master release branch.
223 Making the source tarball
224@@ -403,19 +364,10 @@
225 ``BRZ_DISABLE_PLUGINS`` or ``BRZ_PLUGIN_PATH=-site`` to disable one or
226 all plugins.
228- Until <> is fixed, you may encounter issues if you
229- cut a release for old stable branches (<= 2.2) and use a more recent
230- OS/distro. If that's the case, check the bug status and use the following
231- workaround if no fix is available::
233- export TTPATH=<local branch of lp:testtools -r 0.9.2>
234- export SUPATH=<local branch of lp:subunit -r 0.0.6>
235- PYTHONPATH=$TTPATH:$SUPATH/python PATH=$SUPATH/filters:${PATH} BRZ_PLUGIN_PATH=-site make check-dist-tarball PYTHON=python2.6 | subunit2pyunit
237- Remember that PQM has just tested everything too, this step is
238- particularly testing that the cython extensions, which are updated
239- by your local cython version when you run make dist, are in good
240- shape.
241+ Remember that this branch has already been tested on
242+, this step is particularly testing that the
243+ cython extensions, which are updated by your local cython version when
244+ you run make dist, are in good shape.
247 Publishing the source tarball
248@@ -464,7 +416,7 @@
250 #. ``lp:brz/x.y`` needs to be opened for the next *release* ``x.y.0`` in the
251 series. Since this is first real use of ``lp:brz/x.y``, this is also the
252- deadline for the PQM branch to be created.
253+ deadline for the landing job to be created.
255 Both are important as ``lp:brz`` should remain open so any change can be
256 landed, ``lp:brz/x.y`` on the other hand should be ready to receive bug
257@@ -478,12 +430,8 @@
259 #. Open ``lp:brz`` for ``x.(y+1)``
261-#. Create or update the ``x.y`` PQM branch based on whatever revision you
262- want to release. Since it takes time to create the PQM branch for the new
263- series you should plan to get it created a few days before you need it
264- and seed it with the revision from trunk you want to base your release of
265- (ask a LOSA for pulling this revision from trunk and pushing it to the
266- series branch (``lp:brz/x.y``) when you're ready).
267+#. Create landing job and/or update the
268+ ``lp:brz/x.y`` branch based on whatever revision you want to release.
270 #. Release ``x.y.0`` from ``lp:brz/x.y``
272@@ -606,41 +554,14 @@
273 mentioning the milestone URL <>
274 so people get an easy access to details.
276-#. Announce on
278- This should be done for beta releases and stable releases. If you do not
279- have a Freecode account yet, ask one of the existing admins.
281- The purpose here is to point users to the latest stable release
282- (i.e. SRUs are excluded) while still publishing announcements for beta
283- releases.
285- There are several kinds of modifications that could be done there via the
286- ``Administration`` box in the lower right area of the page:
288- * Edit the project: This is where most of the URLs proposed in the
289- ``Links`` box are edited. This should rarely change except for the URLs
290- related to the latest stable release.
292- * New announcement: When doing a release, put the summary of the release
293- (you can't embed URLs there, the moderation staff remove them). Users
294- can still access the releases notes via the ``Release Notes`` URL in
295- the ``Links`` box in the upper right area of the page. When doing the
296- first stable release in a series, delete the ``Unstable installers``
297- <> and ``Unstable source tarball``
298- <>
299- links. Conversely, when creating the first beta in a development
300- series, create these links again. Check all links when doing other
301- kinds of release.
303 #. Update `<>`_ -- this should
304 be done for the stable and beta releases.
306-#. Update the python package index: <>
307+#. Update the python package index: <>
309 From the tarball created and tested earlier ::
311- twine upload -s ../brz-2.7.0.tar.gz
312+ twine upload -s ../breezy-3.0.0.tar.gz
314 Remember to check the results afterward -- this should be done for
315 stable releases but not for beta releases nor SRUs.
316@@ -666,13 +587,13 @@
317 password:<password on testpypi>
318 repository =
320- Registering the brz project if doesn't exist is achieved with::
321+ Registering the breezy project if doesn't exist is achieved with::
323 python -r register
325 Uploading is done with::
327- twine upload -r testpypi -s ../brz-2.7.0.tar.gz
328+ twine upload -r testpypi -s ../breezy-3.0.0.tar.gz
330 To be able to upload the release you must create an account on
331 <> and have one of the existing owners of the
332@@ -688,7 +609,7 @@
333 has its own release-notes file, but double-check.
335 If it's not already done, advance the version number in ``brz`` and
336-``breezy/``. Submit this back into pqm for
337+``breezy/``. File a merge proposal against ``lp:brz``.
339 As soon as you change the version number in trunk, make sure you have
340 created the corresponding milestone to ensure the continuity in bug
341@@ -714,6 +635,8 @@
342 Getting the release into Ubuntu
343 -------------------------------
345+/!\ Nothing in this section has been validated for breezy yet.
347 (Feel free to propose or add new sections here about what we should do to
348 get brz into other places.)
351=== modified file 'doc/en/_templates/index.html'
352--- doc/en/_templates/index.html 2017-06-02 23:47:28 +0000
353+++ doc/en/_templates/index.html 2018-09-14 09:41:35 +0000
354@@ -24,7 +24,7 @@
355 <span class="linkdescr">a detailed log of changes</span>
356 </p>
357 <p class="biglink"><a class="biglink" href="{{ pathto("upgrade-guide/index") }}">Upgrade Guide</a><br/>
358- <span class="linkdescr">moving to Breezy 2.x</span>
359+ <span class="linkdescr">moving to Breezy 3.x</span>
360 </p>
361 <p class="biglink"><a class="biglink" href="{{ pathto("user-reference/index") }}">User Reference</a><br/>
362 <span class="linkdescr">all the gory details</span>
364=== modified file 'doc/en/index.txt'
365--- doc/en/index.txt 2016-02-01 19:26:41 +0000
366+++ doc/en/index.txt 2018-09-14 09:41:35 +0000
367@@ -10,7 +10,7 @@
368 .. toctree::
369 :maxdepth: 1
371- whats-new/whats-new-in-2.8
372+ whats-new/whats-new-in-3.0
373 user-guide/index
374 tutorials/index
375 quick-reference/index


People subscribed via source and target branches