XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
hits in this file itself.)
- - Now update version numbers in
- * putty/LATEST.VER
- * putty/windows/putty.iss (four times, on consecutive lines)
- * putty/doc/pscp.but (and make sure the rest of the transcript is
- up to date)
- * putty/doc/plink.but (likewise)
+ - Now update the version numbers and the transcripts in the docs, by
+ checking out the release branch and running
+
+ make distclean
+ ./release.pl --set-version=X.YZ
- - Reset the epoch used for the $(Days) value computed in Buildscr for
- the Windows binary version resource. It's probably not a good idea
- to set it to _today_ (since it might clash with the zero-valued
- field used in actual releases), so perhaps we should start it 1000
- days before the release date so as to have a largish number
- recognisable as being the right kind of thing by its order of
- magnitude. So, do this:
+ Then check that the resulting automated git commit has updated the
+ version number in the following places:
- perl -e 'printf "%d\n", time/86400 - 1000'
+ * putty/LATEST.VER
+ * putty/doc/plink.but
+ * putty/doc/pscp.but
+ * putty/windows/putty.iss (four times, on consecutive lines)
- and then substitute the resulting value into the definition of
- 'Epoch' in Buildscr.
+ and also check that it has reset the definition of 'Epoch' in
+ Buildscr.
- - Commit those version number and epoch changes (on the appropriate
- branch, of course!), and then make the release tag pointing at the
- resulting commit.
+ - 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
+ atreus:src/putty-local/announce-<ver> in case it's needed again
within days of the release going out.
- Update the web site, in a local checkout.
pre-releases, if there were any before this release. Comment out
the big pre-release section at the top, and also adjust the
sections about source archives at the bottom.
+ + Do the same on the Docs page.
+ Adjust header text on Changelog page. (That includes changing
`are new' in previous version to `were new'!)
+ .htaccess has an individual redirect for each version number. Add
- Build the release, by checking out the release tag:
git checkout 0.XX
- bob -F . RELEASE=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 that the release binaries basically work,
report their version numbers accurately, and so on. Test the
installer and the Unix source tarball.
- Sign the release: in the `build.out' directory, type
- sh sign.sh putty Releases
+ sh sign.sh -r putty
and enter the passphrases a lot of times.
The actual release procedure
- Save the link maps. Currently I keep these on atreus, in
src/putty-local/maps-<version>.
+ rsync -av maps-x86/ atreus:src/putty-local/maps-X.YZ
- Upload the entire release directory to atreus:www/putty/<version>.
+ rsync -av putty/ atreus:www/putty/X.YZ
- Do final checks on the release directory in its new location:
+ verify all the signatures:
- for i in `find . -name '*.*SA'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.?SA};; esac; done
+ for i in `find . -name '*.gpg'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.gpg};; esac; done
+ check the checksum files:
md5sum -c md5sums
sha1sum -c sha1sums
- Having double-checked the release, copy it from atreus to
chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
+ rsync -av putty/ chiark:ftp/putty-X.YZ
+ rsync -av putty/ the:www/putty/X.YZ
- Check the permissions! Actually try downloading from the, to make
sure it really works.
should do this automatically, owing to the `latest' HTTP
redirect.)
- - Check that the web server attaches the right content type to .HLP
- and .CNT files.
+ - Check that the web server attaches the right content type to .HLP,
+ .CNT and .CHM files, by downloading one of each and checking
+ they're all application/octet-stream.
+ for ext in hlp cnt chm; do curl -v http://the.earth.li/~sgtatham/putty/X.YZ/putty.$ext 2>&1 >/dev/null | grep Content-Type; done
- Run 'git push' in the website checkout, and then 'git pull' in
~/www/putty on atreus to fetch the website updates.