Development/ReleaseManagement

Important points
Freeze schedule
- Patches for the freeze
Workflow
Tricky bits
- Argh! There's a bug in the release candidate
- What happens if we discover a new bug/regression after the release?
Tips
See also

Important points

The release branch lives in http://darcs.net/releases/branch-X.X

Point releases can go on the same branch as their parent release (so branch-2.4 would still be used for Darcs 2.4.1)

Try to work from the main branch if at all possible. By rights all release-branch patches should come from the mainline and flow back to the mainline. This will allow us to do things in the future such as 'darcs changes --from-tag=2.4.3'

Freeze schedule

The basic idea is to have a two-week soft freeze, followed by a two week deep freeze, followed by the release.

As in all Darcs jobs, the Release Manager is expected to change the calendar as needs change, or to adjust the policy in the long term

Here is an example calendar (from our Darcs 2.4 release, which we also had to bend as new bugs cropped up)

Timestamp	Date	Event
N	Thu 31 Dec	Start of soft freeze
N+3	Sun 3 Jan	beta 1 is tagged and released
N+14	Thu 14 Jan	Start of deep freeze
N+17	Sun 17 Jan	beta 2 is tagged and released
N+24	Sun 24 Jan	rc1 is tagged and released
N+30	Sat 30 Jan	final is tagged and released to packagers
N+37	Sat 7 Feb	release is announced

During the soft freeze, only fixes for serious issues and patches achieving release targets will be pulled to the release branch.

During the deep freeze, only release-critical bugfixes will be pulled.

See the release calendar template if you need help sending the calendar email.

Patches for the freeze

Patches that need to go in after a freeze should make this point very clear in the description, lest the Release Manager miss it.

It would be helpful to test and submit these the release branch:

darcs send http://darcs.net/releases/branch-X.X

Workflow

T minus one month

Announce release plans and schedule
Start writing ChangeLog entries
For major releases, create http://wiki.darcs.net/Releases/X.X (see 2.4)
Create release branch on darcs.net (don't forget to set _darcs/prefs/email to darcs-users@darcs.net)

T minus 24 hours

Get a final Target-X.X report from the Issue Manager. The release must not go out until all bugs are accounted for (ie. bumped to next release or resolved)
Record ChangeLog changes
bump version number in darcs.cabal
cabal test && dist/build/unit/unit
Draft release announcement and send to some proofreaders if not beta (while test is running)
darcs tag
release/release.sh

Liftoff!

Darcs push to release branch
Upload tarball to hackage with cabal upload
Put tarball on the darcs website and test it
Change the darcs-unstable@darcs.net:releases/darcs-latest.tar.gz symlink to point to the tarball of the new release
Send release announcement, and put it on http://wiki.darcs.net/Releases/X.X (this gives us a permalink for the release announcement, see Releases/2.4 as an example)
Update darcs homepage by editing doc/index.html and pushing to the HEAD and screened repos
Update the #darcs topic
Stick around for a few days, in case we need a quick X.X.1 fix...

And reentry

One week later...

Send release announcement, and put it on http://wiki.darcs.net/Releases/X.X (this gives us a permalink for the release announcement, see Releases/2.4 as an example)
Celebrate!

Tricky bits

Argh! There's a bug in the release candidate

Good! That means our release process caught something. Give yourself a pat on the QA back.

Now what's the best way to respond to this?

Create an issue on bugs.darcs.net for the bug if doesn't exist yet, and mark its milestone asX.Y.
Release a new RC when this issue has been resolved and the resolution is in the release branch
If the RC has been bug-free for a week, release darcs-X.Y. Otherwise, repeat the above steps.

What happens if we discover a new bug/regression after the release?

Don't panic. This sort of thing happens and the only thing you can really do is to try and cope with it to the best of your ability.

Minor packaging flubs:

you could always make a trivial point release quickly following the original (it happens)
for really minor issues, it should probably not take the packagers any extra time to make a new version

Actual bugs in Darcs:

if it's a really serious regression, you should consider rolling the binaries page on the wiki back so that it points to the last good version
mark the new bugs as milestone X.Y in the tracker
start a new (point) release cycle

A point release cycle:

release an RC that fixes the issue that prompted the point release
As with major releases, tag and release an RC as final after no bugs have been reported for it within a week

Tips

Use the buildbots. You should (ideally) only pull patches from unstable that pass buildbots

darcs changes --from-tag=last_version > foo

and copy foo into the ChangeLog and edit it

Advice on ChangeLogs, announcements: How we write Launchpad announcements
Send release announcements to darcs-users and haskell-cafe for prereleases and to darcs-users, haskell-cafe and haskell for final releases. Reinier once sent release announcements to the mailing lists of our colleagues of git and bazaar, but this was not universally well-received.