This page is a guide for anyone taking the role of Release Manager (RM) for an Angband release series. A release series is defined as including all values of Z in the version number X.Y.Z, e.g. 3.3.0, 3.3.1 and 3.3.2 were all part of a single series. The RM has a lot of responsibility for testing, managing and announcing the releases in the series, but in return has final veto over exactly which commits are included in his/her releases.
Before releasing X.Y.0
Review the state of the X.Y-dev master branch. See how it compares against
- the roadmap for the X.Y.0 milestone
- the existing tickets for the X.Y.0 milestone
- the public aspirations of any active devs (though these should be captured as tickets)
- also check the Triage tickets for any that you can personally triage - if they are platform-specific and you can't, then don't worry about them
After checking with other devs to see who is likely to be able to contribute features, triaging or bugfixes in your chosen timescale, update the "Goals for X.Y" page with a definitive statement of what you expect to see in X.Y.0, including a list of tickets that you really want closed - note that this is unlikely to be the full set of tickets tagged for X.Y.0. Other people can take stuff out (e.g. if they aren't going to be able to finish it in time), but nobody can add anything else in without your agreement.
When you're happy with it, or you run out of patience with the owners of outstanding tickets, declare a Release Candidate (RC):
- on the master branch, run "git tag -a vX.Y.0-RC1" and then "git push official tag vX.Y.0-RC1"
- announce the RC in the Vanilla forum on Oook, linking to the build at http://buildbot.rephial.org/builds/master/builds.html
- allow at least two weeks for people to playtest it
If there are confirmed, reproducible bugs in the RC, make sure people make tickets for them, and see if anyone can fix them. Once all the important bugs are fixed to your satisfaction (you may choose to leave tiny ones), repeat the process above for RC2. If that turns up major bugs, repeat for RC3 and so on.
Once you are happy with an RC as bug-free, declare it as X.Y.0 by following the process on the ReleaseChecklist page. For the X.Y.0 release, you will also need to create a new branch for that series with "git checkout -b X.Y-release" and "git push official X.Y-release". You are the owner of this branch and the only person who should push to it. Development of X.Y+1-dev will continue in master - this branch is solely for the creation of X.Y.1 and any subsequent releases.
After you've made the .0 release, punt any remaining X.Y.0 tickets to milestone Future. It is up to those who own them to decide which milestone they want to aim for.
Releasing X.Y.1 et seq.
If you are extremely lucky, your RCs will have found all the bugs, and your job is done. More likely, since many more people play a .0 release than an RC, new bugs will be reported. Again, make sure there are tickets for any that can be reproduced reliably, or (even if they can't) for those reported by more than one person. These tickets should use the X.Y.1 milestone. It isn't your job to fix them all, but to draw them to the attention of those who can.
When you're ready - maybe when there's a tailing-off of new bug reports, and no really nasty ones remain - repeat the above process for X.Y.1-RC1. With luck you won't need more than one RC for any .Z release. If it's just a fix for a single show-stopping bug (for example, if some idiot made leather boots ten times as common as they should be), you may decide to skip an RC altogether.
When you're happy to release, don't forget to go through ReleaseChecklist again.
Don't be tempted to add new features to .Z releases; they are for improved performance of the .0 feature set. If people want to rush to release a fancy new feature, tell them to step up as RM for the X.Y+1 series and do it themselves.