X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=blobdiff_plain;f=CHECKLST.txt;h=51e11593cdbafa15b674dd9148b4642e95cb5ea1;hb=222c134b5f4f5397f2a15d36813286edeb3cff5e;hp=18c2d18f4ea2903a7da0281e46c16cfbc238f128;hpb=7fd8b8bb1606401051c6b4866b2b3cb7edadbc65;p=PuTTY.git diff --git a/CHECKLST.txt b/CHECKLST.txt index 18c2d18f..51e11593 100644 --- a/CHECKLST.txt +++ b/CHECKLST.txt @@ -64,36 +64,32 @@ for it: 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- in case it's needed again + atreus:src/putty-local/announce- in case it's needed again within days of the release going out. - Update the web site, in a local checkout. @@ -106,6 +102,7 @@ for it: 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 @@ -121,17 +118,20 @@ for it: - 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 @@ -142,12 +142,14 @@ locally, this is the procedure for putting it up on the web. - Save the link maps. Currently I keep these on atreus, in src/putty-local/maps-. + rsync -av maps-x86/ atreus:src/putty-local/maps-X.YZ - Upload the entire release directory to atreus:www/putty/. + 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 @@ -156,6 +158,8 @@ locally, this is the procedure for putting it up on the web. - Having double-checked the release, copy it from atreus to chiark:ftp/putty- and to the:www/putty/. + 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. @@ -170,8 +174,10 @@ locally, this is the procedure for putting it up on the web. 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.