~bzr-pqm/bzr/bzr.dev

Viewing changes to doc/developers/releasing.txt

Committer: Canonical.com Patch Queue Manager
Date: 2009-08-30 22:15:30 UTC
mfrom: (4663.1.1 integration)
Revision ID: pqm@pqm.ubuntu.com-20090830221530-cyl2ubhnn49s05m2

(robertc) Merge 2.0 to bzr.dev,
including fixes for log and serialisation of
IncompatibleRepositories. (Robert Collins, John Arbash Meinel)

files modified:
NEWS

bzrlib/__init__.py

bzrlib/groupcompress.py

bzrlib/knit.py

bzrlib/tests/per_versionedfile.py

doc/developers/releasing.txt

Show diffs side-by-side

added added

removed removed

doc/developers/releasing.txt

bzr branch lp:bzr-pqm ~/.bazaar/plugins/pqm

Starting the release phase

--------------------------

When it's time to make the release candidate:

Starting a cycle

----------------

To start a new release cycle:

#. Create a new series at <https://launchpad.net/bzr/+addseries>. There is one

series for every *x.y* release.

#. Go to the series web page at <https://launchpad.net/bzr/2.0>

#. Create a new release at

<https://launchpad.net/bzr/2.0/+addrelease> and add

information about this release. We will not use it yet, but it

will be available for targeting or nominating bugs.

#. We create a new pqm-controlled branch for this release series, by

asking a Canonical sysadmin.

This branch means that from the first release candidate onwards,

This branch means that from the first release beta or candidate onwards,

general development continues on the trunk, and only

specifically-targetted fixes go into the release.

#. Register the branch at <https://launchpad.net/products/bzr/+addbranch>

#. Make a release candidate.

specifically-targeted fixes go into the release branch.

#. Add milestones at <https://edge.launchpad.net/bzr/2.0/+addmilestone> to

that series for the beta release, release candidate and the final release,

and their expected dates.

#. Update the version number in the ``bzr`` script, and the

``bzrlib/__init__.py`` file.

#. Send mail to the list with the key dates, who will be the release

manager, and the main themes or targeted bugs. Ask people to nominate

objectives, or point out any high-risk things that are best done early,

or that interact with other changes. This is called the metronome mail

and as RM you're supposed to send other metronome mails at your rythm.

Starting the release phase

--------------------------

When it's time to make the first beta release or release candidate:

#. Create a new milestone at <https://launchpad.net/bzr/2.0/+addmilestone>

for the beta release or release candidate.

#. Make a beta release or release candidate.

Preparing the tree for release

------------------------------

[/home/mbp/bzr/prepare-1.14]

pqm_email = Canonical PQM <pqm@bazaar-vcs.org>

submit_branch = http://bazaar-vcs.org/bzr/bzr.1.14

public_branch = http://bazaar.your-domain.com/bzr

submit_branch = lp:bzr/2.0

public_branch = http://bazaar.example.com/prepare-2.0

submit_to = bazaar@lists.canonical.com

smtp_server = mail.your-domain.com:25

smtp_server = mail.example.com:25

Please see <http://doc.bazaar-vcs.org/latest/developers/HACKING.html#an-overview-of-pqm>

for more details on PQM

#. In the release branch, update ``version_info`` in ``./bzrlib/__init__.py``.

Double check that ./bzr ``_script_version`` matches ``version_info``. Check

the output of ``bzr --version``.

For beta releases use::

version_info = (2, 1, 0, 'beta', 1)

For release candidates use::

version_info = (2, 0, 1, 'candidate', 1)

100

101

#. Add the date and release number to ``./NEWS``

102

141

181

142

182

make check-dist-tarball

143

183

184

You may encounter failures while running the test suite caused

185

by your locally installed plugins. Use your own judgment to

186

decide if you can release with these failures. When in doubt,

187

disable the faulty plugins one by one until you get no more

188

failures.

189

144

190

145

191

Publishing the release

146

192

----------------------

147

193

148

Now you have the releasable product. The next step is making it

194

Now you have the beta or releasable product. The next step is making it

149

195

available to the world.

150

196

151

#. In <https://launchpad.net/bzr/> click the "Release series" for this

152

series, to take you to e.g. <https://launchpad.net/bzr/1.14>. Then

153

click "Register a release", and add information about this release.

197

go to the release

154

198

155

199

#. Within that release, upload the source tarball and zipfile and the GPG

156

200

signature. Or, if you prefer, use the

160

204

161

205

#. Announce on the `Bazaar home page <http://bazaar-vcs.org/>`_.

162

206

163

#. Check that the documentation for this release is available in

164

<http://doc.bazaar-vcs.org>. It should be automatically build when the

207

#. Check that the documentation for this release is available in

208

<http://doc.bazaar-vcs.org>. It should be automatically build when the

165

209

branch is created, by a cron script ``update-bzr-docs`` on

166

``escudero``.

210

``escudero``. As of today (2009-08-27) ``igc`` manually updates the

211

pretty version of it.

167

212

168

213

169

214

Announcing the release

173

218

174

219

#. Make an announcement mail.

175

220

176

For release candidates, this is sent to the ``bazaar-announce`` and

177

``bazaar`` lists. For final releases, it should also be cc'd to

178

``info-gnu@gnu.org``, ``python-announce-list@python.org``,

179

``bug-directory@gnu.org``. In both cases, it is good to set

180

``Reply-To: bazaar@lists.canonical.com``, so that people who reply to

181

the announcement don't spam other lists.

221

For release candidates or beta releases, this is sent to the ``bazaar``

222

list only to inform plugin authors and package or installer managers.

223

224

Once the installers are available, the mail can be sent to the

225

``bazaar-announce`` list too.

226

227

For final releases, it should also be cc'd to ``info-gnu@gnu.org``,

228

``python-announce-list@python.org``, ``bug-directory@gnu.org``.

229

230

In all cases, it is good to set ``Reply-To: bazaar@lists.canonical.com``,

231

so that people who reply to the announcement don't spam other lists.

182

232

183

233

The announce mail will look something like this::

184

234

208

258

209

259

#. Announce on http://freshmeat.net/projects/bzr/

210

260

211

This should be done for both release candidates and final releases. If

212

you do not have a Freshmeat account yet, ask one of the existing

213

admins.

261

This should be done for beta releases, release candidates and final

262

releases. If you do not have a Freshmeat account yet, ask one of the

263

existing admins.

214

264

215

#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should be done

216

for final releases but not for Release Candidates.

265

#. Update `<http://en.wikipedia.org/wiki/Bazaar_(software)>`_ -- this should

266

be done for final releases but not for beta releases or Release Candidates.

217

267

218

268

#. Update the python package index: <http://pypi.python.org/pypi/bzr> - best

219

269

done by running ::

240

290

at any time.

241

291

242

292

243

Starting a cycle

244

----------------

245

246

To start a new release cycle:

247

248

#. Send mail to the list with the key dates, who will be the release

249

manager, and the main themes or targeted bugs. Ask people to nominate

250

objectives, or point out any high-risk things that are best done early,

251

or that interact with other changes.

252

253

#. Add a new "series" in Launchpad at <https://launchpad.net/bzr/+addseries>.

254

There is one series for every *x.y* release.

255

256

#. Add milestones to that series for the release candidate and the final

257

release, and their expected dates.

258

259

#. Deactivate old releases and their milestones.

260

261

#. Update the version number in the ``bzr`` script, and the

262

``bzrlib/__init__.py`` file.

263

264

265

293