X-Git-Url: https://asedeno.scripts.mit.edu/gitweb/?a=blobdiff_plain;f=CHECKLST.txt;h=51e11593cdbafa15b674dd9148b4642e95cb5ea1;hb=222c134b5f4f5397f2a15d36813286edeb3cff5e;hp=93996f8d4d957b9573b5bbd4ddcc296355c1eeb7;hpb=11eb75a260ca1c6e48a19afe241d423f6e7b0e4e;p=PuTTY.git

diff --git a/CHECKLST.txt b/CHECKLST.txt
index 93996f8d..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.
@@ -146,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-<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:
@@ -160,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-<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.
@@ -174,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.