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- 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: * Subject: PuTTY X.YZ is released + Mail that release announcement to . + Post it to comp.security.ssh. + Mention it in on mono. - Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were previously enabled. - Relax (slightly).