Big revision to CHECKLST.txt for release.pl and Mason.

Half the release checklist has changed recently, what with me
completely reworking the website and also writing all this release
automation. I think these are all the checklist changes needed now the
dust has settled, though of course when I do the next actual release I
expect there'll turn out to be something I missed...

CHECKLST.txt

@@ -35,10 +35,6 @@ The documentation (both the preamble blurb and the licence appendix):
  - putty/doc/blurb.but
  - putty/doc/licence.but
 
-The website:
-
- - putty-website/licence.html
-
 Preparing to make a release
 ---------------------------
 
@@ -68,7 +64,7 @@ for it:
    checking out the release branch and running
 
       make distclean
-      ./release.pl --set-version=X.YZ
+      ./release.pl --version=X.YZ --setver
 
    Then check that the resulting automated git commit has updated the
    version number in the following places:
@@ -92,29 +88,23 @@ for it:
    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.
+ - Update the website, in a local checkout:
-   + Adjust front page to say 'The latest version is <ver>'.
+    * Write a release file in components/releases which identifies the
-   + Adjust front page to add a news item.
+      new version, its release date, a section for the Changes page,
-   + Adjust Download page to say 'The latest release version (<ver>)'.
+      and a news announcement for the front page.
-   + Adjust Download page to update filenames of installer and Unix
+    * Disable the pre-release sections of the website (if previously
-     tarball (both in the hrefs themselves and the link text).
+      enabled), by editing prerel_version() in components/Base.mc to
-   + Check over the Download page and remove any mention of
+      return undef.
-     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
-     a new one.
 
- - If there are any last-minute wishlist entries (e.g. security
+ - Update the wishlist, in a local checkout:
-   vulnerabilities fixed in the new release), write entries for them
+    * If there are any last-minute wishlist entries (e.g. security
-   in a local checkout of putty-wishlist.
+      vulnerabilities fixed in the new release), write entries for
-
+      them.
- - Update the wishlist mechanism for the new release. This can be done
+    * If any other bug fixes have been cherry-picked to the release
-   without touching individual items by editing the @releases array in
+      branch (so that the wishlist mechanism can't automatically mark
-   control/bugs2html.
+      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
@@ -126,9 +116,13 @@ for it:
  - 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,
+ - Do a bit of checking of the release binaries:
-   report their version numbers accurately, and so on. Test the
+    * make sure they basically work
-   installer and the Unix source tarball.
+    * 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
@@ -140,61 +134,36 @@ 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.
 
- - Save the link maps. Currently I keep these on atreus, in
+ - Upload the release itself and its link maps to everywhere it needs
-   src/putty-local/maps-<version>.
+   to be, by running this in the build.out directory:
-      rsync -av maps-x86/ atreus:src/putty-local/maps-X.YZ
+      ../release.pl --version=X.YZ --upload
 
- - Upload the entire release directory to atreus:www/putty/<version>.
+ - Check that downloads via version-numbered URLs all work:
-      rsync -av putty/ atreus:www/putty/X.YZ
+      ../release.pl --version=X.YZ --precheck
 
- - Do final checks on the release directory in its new location:
+ - Switch the 'latest' links over to the new release:
-    + verify all the signatures:
+    * Update the HTTP redirect at the:www/putty/htaccess .
-      for i in `find . -name '*.gpg'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.gpg};; esac; done
+    * Update the FTP symlink at chiark:ftp/putty-latest .
-    + check the checksum files:
-      md5sum -c md5sums
-      sha1sum -c sha1sums
-      sha256sum -c sha256sums
-      sha512sum -c sha512sums
 
- - Having double-checked the release, copy it from atreus to
+ - Now verify that downloads via the 'latest' URLs are all redirected
-   chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
+   correctly and work:
-      rsync -av putty/ chiark:ftp/putty-X.YZ
+      ../release.pl --version=X.YZ --postcheck
-      rsync -av putty/ the:www/putty/X.YZ
 
- - Check the permissions! Actually try downloading from the, to make
+ - Push all the git repositories:
-   sure it really works.
+    * 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
 
- - Update the HTTP redirect at the:www/putty/htaccess which points the
+ - Run ~/adm/puttyweb.sh on atreus to update the website after all
-   virtual subdir `latest' at the actual latest release dir. TEST THIS
+   those git pushes.
-   ONE - it's quite important.
 
- - Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
+ - Check that the unpublished website on atreus looks sensible.
-
- - Check the Docs page links correctly to the release docs. (It
-   should do this automatically, owing to the `latest' HTTP
-   redirect.)
-
- - 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.
-
- - Push the changes to PuTTY itself. Something like:
-     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 'git push' in the putty-wishlist checkout. Then run 'git pull'
-   in ~/pub/putty-wishlist on atreus, and update the wishlist web
-   pages with the commands
-     cd ~/pub/putty-wishlist/control
-     perl bugs2html
-
- - Check over the web site to make sure all the changes to wishlist
-   and main web pages are present and correct.
 
  - Run webupdate, so that all the changes on atreus propagate to
    chiark. Important to do this _before_ announcing that the release