X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=blobdiff_plain;f=CHECKLST.txt;h=51e11593cdbafa15b674dd9148b4642e95cb5ea1;hb=222c134b5f4f5397f2a15d36813286edeb3cff5e;hp=78e9d22317bf5e0a7e0b838d904449246fb60e62;hpb=7524da621b1689b3384020cd6d83c990ef86bfa1;p=PuTTY.git diff --git a/CHECKLST.txt b/CHECKLST.txt index 78e9d223..51e11593 100644 --- a/CHECKLST.txt +++ b/CHECKLST.txt @@ -64,29 +64,25 @@ 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. @@ -112,11 +108,6 @@ for it: + .htaccess has an individual redirect for each version number. Add a new one. - - For 0.66 only: if it's not already done, switch the remaining - signature links on the Download page over to using the new - signature style. Then remove this checklist item, since it'll only - need doing this once. - - If there are any last-minute wishlist entries (e.g. security vulnerabilities fixed in the new release), write entries for them in a local checkout of putty-wishlist. @@ -151,8 +142,10 @@ 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: @@ -165,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. @@ -179,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.