Checklists for PuTTY administrative procedures ============================================== Locations of the licence ------------------------ The PuTTY copyright notice and licence are stored in quite a few places. At the start of a new year, the copyright year needs updating in all of them; and when someone sends a massive patch, their name needs adding in all of them too. The LICENCE file in the main source distribution: - putty/LICENCE The resource files: - putty/windows/pageant.rc + the copyright date appears twice, once in the About box and once in the Licence box. Don't forget to change both! - putty/windows/puttygen.rc + the copyright date appears twice, once in the About box and once in the Licence box. Don't forget to change both! - putty/windows/win_res.rc2 + the copyright date appears twice, once in the About box and once in the Licence box. Don't forget to change both! - putty/windows/version.rc2 + the copyright date appears once only. - putty/unix/gtkdlg.c + the copyright date appears twice, once in the About box and once in the Licence box. Don't forget to change both! The documentation (both the preamble blurb and the licence appendix): - putty/doc/blurb.but - putty/doc/licence.but 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).