Fetching contributors…
Cannot retrieve contributors at this time
157 lines (122 sloc) 5.97 KB
Checklists for PuTTY administrative procedures
==============================================
Preparing to make a release
---------------------------
Now that PuTTY is in git, a lot of the release preparation can be done
in advance, in local checkouts, and not pushed until the actual
process of _releasing_ it.
To begin with, before dropping the tag, make sure everything is ready
for it:
- First of all, go through the source (including the documentation),
and the website, and review anything tagged with a comment
containing the word XXX-REVIEW-BEFORE-RELEASE.
(Any such comments should state clearly what needs to be done.)
- Also, do some testing of the Windows version with Minefield, and
of the Unix version with valgrind or efence or both. In
particular, any headline features for the release should get a
workout with memory checking enabled!
- Double-check that we have removed anything tagged with a comment
containing the words XXX-REMOVE-BEFORE-RELEASE or
XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
hits in this file itself.)
- Now update the version numbers and the transcripts in the docs, by
checking out the release branch and running
make distclean
./release.pl --version=X.YZ --setver
Then check that the resulting automated git commit has updated the
version number in the following places:
* putty/LATEST.VER
* putty/doc/plink.but
* putty/doc/pscp.but
* putty/windows/putty.iss (four times, on consecutive lines)
and also check that it has reset the definition of 'Epoch' in
Buildscr.
- Make the release tag, pointing at the version-update commit we just
generated.
- If the release is on a branch (which I expect it generally will
be), merge that branch to master.
- Write a release announcement (basically a summary of the changes
since the last release). Squirrel it away in
atreus:src/putty-local/announce-<ver> in case it's needed again
within days of the release going out.
- Update the website, in a local checkout:
* Write a release file in components/releases which identifies the
new version, its release date, a section for the Changes page,
and a news announcement for the front page.
* Disable the pre-release sections of the website (if previously
enabled), by editing prerel_version() in components/Base.mc to
return undef.
- Update the wishlist, in a local checkout:
* If there are any last-minute wishlist entries (e.g. security
vulnerabilities fixed in the new release), write entries for
them.
* If any other bug fixes have been cherry-picked to the release
branch (so that the wishlist mechanism can't automatically mark
them as fixed in the new release), add appropriate Fixed-in
headers for those.
* Add an entry to the @releases array in control/bugs2html.
- Build the release, by checking out the release tag:
git checkout 0.XX
bob . RELEASE=0.XX
This should generate a basically valid release directory as
`build.out/putty', and provide link maps and sign.sh alongside that
in build.out.
- Double-check in build.log that the release was built from the right
git commit.
- Do a bit of checking of the release binaries:
* make sure they basically work
* check they report the right version number
* if there's any easily observable behaviour difference between
the release branch and master, arrange to observe it
* test the Windows installer
* test the Unix source tarball.
- Sign the release: in the `build.out' directory, type
sh sign.sh -r putty
and enter the passphrases a lot of times.
The actual release procedure
----------------------------
Once all the above preparation is done and the release has been built
locally, this is the procedure for putting it up on the web.
- Upload the release itself and its link maps to everywhere it needs
to be, by running this in the build.out directory:
../release.pl --version=X.YZ --upload
- Check that downloads via version-numbered URLs all work:
../release.pl --version=X.YZ --precheck
- Switch the 'latest' links over to the new release:
* Update the HTTP redirect at the:www/putty/htaccess .
* Update the FTP symlink at chiark:ftp/putty-latest .
- Now verify that downloads via the 'latest' URLs are all redirected
correctly and work:
../release.pl --version=X.YZ --postcheck
- Push all the git repositories:
* run 'git push' in the website checkout
* run 'git push' in the wishlist checkout
* push from the main PuTTY checkout. Typically this one will be
pushing both the release tag and an update to the master branch,
plus removing the pre-release branch, so you'll want some
commands along these lines:
git push origin master # update the master branch
git push origin --tags # should push the new release tag
git push origin :pre-0.XX # delete the pre-release branch
- Run ~/adm/puttyweb.sh on atreus to update the website after all
those git pushes.
- Check that the unpublished website on atreus looks sensible.
- Run webupdate, so that all the changes on atreus propagate to
chiark. Important to do this _before_ announcing that the release
is available.
- After running webupdate, run update-rsync on chiark and verify that
the rsync mirror package (~/ftp/putty-website-mirror) contains a
subdirectory for the new version and mentions it in its .htaccess.
- Announce the release!
+ Construct a release announcement email whose message body is the
announcement written above, and which includes the following
headers:
* Reply-To: <putty@projects.tartarus.org>
* Subject: PuTTY X.YZ is released
+ Mail that release announcement to
<putty-announce@lists.tartarus.org>.
+ Post it to comp.security.ssh.
+ Mention it in <TDHTT> on mono.
- Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were
previously enabled.
- Relax (slightly).