Modifications to the release procedure as a result of actually
[u/mdw/putty] / CHECKLST.txt
index 34f592f..657d775 100644 (file)
@@ -25,6 +25,9 @@ The resource files:
     + the copyright date appears twice, once in the About box and
       once in the Licence box. Don't forget to change both!
  - putty/mac/mac_res.r
+ - putty/unix/gtkdlg.c
+    + the copyright date appears twice, once in the About box and
+      once in the Licence box. Don't forget to change both!
 
 The documentation (both the preamble blurb and the licence appendix):
 
@@ -34,7 +37,7 @@ The documentation (both the preamble blurb and the licence appendix):
 The website:
 
  - putty-website/licence.html
+
 Before tagging a release
 ------------------------
 
@@ -62,6 +65,16 @@ resources -- the strings are supplied by the usual means):
 
  - putty/mac/version.r
 
+It might also be worth going through the documentation looking for
+version numbers - we have a couple of transcripts showing the help
+text from the command-line tools, and it would be nice to ensure the
+whole transcripts (certainly including the version numbers) are up
+to date.
+
+ - putty/doc/pscp.but
+ - putty/doc/plink.but
+ - putty/doc/psftp.but (in case it ever acquires a similar thing)
+
 The actual release procedure
 ----------------------------
 
@@ -75,30 +88,41 @@ of the tag.
    within days of the release going out.
 
  - On my local machines, check out the release-tagged version of the
-   sources.
+   sources. Do this in a _clean_ directory; don't depend on my usual
+   source dir.
     + Make sure to run mkfiles.pl _after_ this checkout, just in
       case.
 
+ - Build the source archives now, while the directory is still
+   pristine.
+    + run ./mksrcarc.sh to build the Windows source zip.
+    + run `./mkunxarc.sh X.YZ' to build the Unix tarball.
+
  - Build the Windows/x86 release binaries. Don't forget to supply
    VER=/DRELEASE=<ver>. Run them, or at least one or two of them, to
    ensure that they really do report their version number correctly.
+    + Save the release link maps. Currently I keep these on ixion,
+      in src/putty/local/maps-<version>.
 
  - Acquire the Windows/alpha release binaries from Owen.
-    + Verify the snapshot-key signatures on these, to ensure they're
-      really the ones he built. If I'm going to snapshot-sign a zip
-      file I make out of these, I'm damn well going to make sure the
-      binaries that go _into_ it were snapshot-signed themselves.
+    + Verify the signatures on these, to ensure they're really the
+      ones he built. If I'm going to sign a zip file I make out of
+      these, I'm damn well going to make sure the binaries that go
+      _into_ it are signed themselves.
+    + Make sure Owen has kept the Alpha release link maps somewhere
+      useful.
 
  - Run Halibut to build the docs.
 
- - Build the .zip files.
-    + The binary archive putty.zip just contains all the .exe files
-      except PuTTYtel, and the .hlp and .cnt files.
-    + The source archive putty-src.zip is built by puttysnap.sh (my
-      cron script that also builds the nightly snapshot source
-      archive).
-    + The docs archive puttydoc.zip contains all the HTML files
-      output from Halibut.
+ - Build the binary archives putty.zip (one for each architecture):
+   each one just contains all the .exe files except PuTTYtel, and
+   the .hlp and .cnt files.
+    + zip -k putty.zip `ls *.exe | grep -v puttytel` putty.hlp putty.cnt
+    + same again for Alpha.
+
+ - Build the docs archive puttydoc.zip: it contains all the HTML
+   files output from Halibut.
+    + zip puttydoc.zip *.html
 
  - Build the installer.
 
@@ -107,15 +131,9 @@ of the tag.
       binary zipfile, and the locally built x86 installer, with the
       release keys.
     + The Alpha binaries should already have been signed with the
-      snapshot keys. Having checked that, sign the Alpha binary
-      zipfile with the snapshot keys too.
+      release keys. Having checked that, sign the Alpha binary
+      zipfile with the release keys too.
     + The source archive should be signed with the release keys.
-      This was the most fiddly bit of the last release I did: the
-      script that built the source archive was on ixion, so I had to
-      bring the archive back to my local machine, check everything
-      in it was untampered-with, and _then_ sign it. Perhaps next
-      time I should arrange that puttysnap.sh can run on my local
-      box; it'd be a lot easier.
     + Don't forget to sign with both DSA and RSA keys for absolutely
       everything.
 
@@ -124,24 +142,25 @@ of the tag.
       installer, and all signatures on the above.
     + subdir `alpha' containing the Alpha binaries, Alpha binary
       zip, and all signatures on the above.
-    + top-level dir contains the source zip (plus signatures),
+    + top-level dir contains the Windows source zip (plus
+      signatures), the Unix source tarball (plus signatures),
       puttydoc.txt, the .hlp and .cnt files, and puttydoc.zip.
 
  - Create and sign md5sums files: one in the x86 subdir, one in the
    alpha subdir, and one in the parent dir of both of those.
     + The md5sums files need not list the .DSA and .RSA signatures,
       and the top-level md5sums need not list the other two.
-    + Sign the md5sums files (gpg --clearsign). The Alpha md5sums
-      should be signed with the snapshot keys, but the other two
-      with the release keys (yes, the top-level one includes some
-      Alpha files, but I think people will understand).
+    + Sign the md5sums files (gpg --clearsign).
 
  - Now double-check by verifying all the signatures on all the
-   files.
+   files, and running md5sum -c on all the md5sums files.
 
  - Create subdir `htmldoc' in the release directory, which should
    contain exactly the same set of HTML files that went into
    puttydoc.zip.
+    + It also needs a copy of sitestyle.css, because the online
+      versions of the HTML docs will link to this (although the
+      zipped form should be self-contained).
 
  - Now the whole release directory should be present and correct.
    Upload to ixion:www/putty/<ver>, upload to
@@ -158,10 +177,15 @@ of the tag.
 
  - Update web site.
    + Adjust front page (`the latest version is <ver>').
-   + Adjust filename of installer on links in Download page.
+   + Adjust Download page similarly.
+   + Adjust filenames of installer and Unix tarball on links in
+     Download page.
    + Adjust header text on Changelog page. (That includes changing
      `are new' in previous version to `were new'!)
 
+ - Update the wishlist. This can be done without touching individual
+   items by editing the @releases array in control/bugs2html.
+
  - Check the Docs page links correctly to the release docs. (It
    should do this automatically, owing to the `latest' HTTP
    redirect.)
@@ -176,7 +200,6 @@ of the tag.
  - Announce the release!
     + Mail the announcement to putty-announce.
     + Post it to comp.security.ssh.
-    + Mention it in <TDHIS> on mono.
+    + Mention it in <TDHTT> on mono.
 
- - All done. Probably best to run `cvs up -A' now, or I'll only
-   forget in a few days' time and get confused...
+ - All done.