CHECKLST.txt

   1 Checklists for PuTTY administrative procedures
   2 ==============================================
   3
   4 Locations of the licence
   5 ------------------------
   6
   7 The PuTTY copyright notice and licence are stored in quite a few
   8 places. At the start of a new year, the copyright year needs
   9 updating in all of them; and when someone sends a massive patch,
  10 their name needs adding in all of them too.
  11
  12 The LICENCE file in the main source distribution:
  13
  14  - putty/LICENCE
  15
  16 The resource files:
  17
  18  - putty/windows/pageant.rc
  19     + the copyright date appears twice, once in the About box and
  20       once in the Licence box. Don't forget to change both!
  21  - putty/windows/puttygen.rc
  22     + the copyright date appears twice, once in the About box and
  23       once in the Licence box. Don't forget to change both!
  24  - putty/windows/win_res.rc2
  25     + the copyright date appears twice, once in the About box and
  26       once in the Licence box. Don't forget to change both!
  27  - putty/windows/version.rc2
  28     + the copyright date appears once only.
  29  - putty/unix/gtkdlg.c
  30     + the copyright date appears twice, once in the About box and
  31       once in the Licence box. Don't forget to change both!
  32
  33 The documentation (both the preamble blurb and the licence appendix):
  34
  35  - putty/doc/blurb.but
  36  - putty/doc/licence.but
  37
  38 The website:
  39
  40  - putty-website/licence.html
  41
  42 Preparing to make a release
  43 ---------------------------
  44
  45 Now that PuTTY is in git, a lot of the release preparation can be done
  46 in advance, in local checkouts, and not pushed until the actual
  47 process of _releasing_ it.
  48
  49 To begin with, before dropping the tag, make sure everything is ready
  50 for it:
  51
  52  - First of all, go through the source (including the documentation),
  53    and the website, and review anything tagged with a comment
  54    containing the word XXX-REVIEW-BEFORE-RELEASE.
  55    (Any such comments should state clearly what needs to be done.)
  56
  57  - Also, do some testing of the Windows version with Minefield, and
  58    of the Unix version with valgrind or efence or both. In
  59    particular, any headline features for the release should get a
  60    workout with memory checking enabled!
  61
  62  - Double-check that we have removed anything tagged with a comment
  63    containing the words XXX-REMOVE-BEFORE-RELEASE or
  64    XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
  65    hits in this file itself.)
  66
  67  - Now update the version numbers and the transcripts in the docs, by
  68    checking out the release branch and running
  69
  70       make distclean
  71       ./release.pl --set-version=X.YZ
  72
  73    Then check that the resulting automated git commit has updated the
  74    version number in the following places:
  75
  76     * putty/LATEST.VER
  77     * putty/doc/plink.but
  78     * putty/doc/pscp.but
  79     * putty/windows/putty.iss (four times, on consecutive lines)
  80
  81    and also check that it has reset the definition of 'Epoch' in
  82    Buildscr.
  83
  84  - Make the release tag, pointing at the version-update commit we just
  85    generated.
  86
  87  - If the release is on a branch (which I expect it generally will
  88    be), merge that branch to master.
  89
  90  - Write a release announcement (basically a summary of the changes
  91    since the last release). Squirrel it away in
  92    atreus:src/putty-local/announce-<ver> in case it's needed again
  93    within days of the release going out.
  94
  95  - Update the web site, in a local checkout.
  96    + Adjust front page to say 'The latest version is <ver>'.
  97    + Adjust front page to add a news item.
  98    + Adjust Download page to say 'The latest release version (<ver>)'.
  99    + Adjust Download page to update filenames of installer and Unix
 100      tarball (both in the hrefs themselves and the link text).
 101    + Check over the Download page and remove any mention of
 102      pre-releases, if there were any before this release. Comment out
 103      the big pre-release section at the top, and also adjust the
 104      sections about source archives at the bottom.
 105    + Do the same on the Docs page.
 106    + Adjust header text on Changelog page. (That includes changing
 107      `are new' in previous version to `were new'!)
 108    + .htaccess has an individual redirect for each version number. Add
 109      a new one.
 110
 111  - If there are any last-minute wishlist entries (e.g. security
 112    vulnerabilities fixed in the new release), write entries for them
 113    in a local checkout of putty-wishlist.
 114
 115  - Update the wishlist mechanism for the new release. This can be done
 116    without touching individual items by editing the @releases array in
 117    control/bugs2html.
 118
 119  - Build the release, by checking out the release tag:
 120      git checkout 0.XX
 121      bob . RELEASE=0.XX
 122    This should generate a basically valid release directory as
 123    `build.out/putty', and provide link maps and sign.sh alongside that
 124    in build.out.
 125
 126  - Double-check in build.log that the release was built from the right
 127    git commit.
 128
 129  - Do a bit of checking that the release binaries basically work,
 130    report their version numbers accurately, and so on. Test the
 131    installer and the Unix source tarball.
 132
 133  - Sign the release: in the `build.out' directory, type
 134      sh sign.sh -r putty
 135    and enter the passphrases a lot of times.
 136
 137 The actual release procedure
 138 ----------------------------
 139
 140 Once all the above preparation is done and the release has been built
 141 locally, this is the procedure for putting it up on the web.
 142
 143  - Save the link maps. Currently I keep these on atreus, in
 144    src/putty-local/maps-<version>.
 145       rsync -av maps-x86/ atreus:src/putty-local/maps-X.YZ
 146
 147  - Upload the entire release directory to atreus:www/putty/<version>.
 148       rsync -av putty/ atreus:www/putty/X.YZ
 149
 150  - Do final checks on the release directory in its new location:
 151     + verify all the signatures:
 152       for i in `find . -name '*.gpg'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.gpg};; esac; done
 153     + check the checksum files:
 154       md5sum -c md5sums
 155       sha1sum -c sha1sums
 156       sha256sum -c sha256sums
 157       sha512sum -c sha512sums
 158
 159  - Having double-checked the release, copy it from atreus to
 160    chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
 161       rsync -av putty/ chiark:ftp/putty-X.YZ
 162       rsync -av putty/ the:www/putty/X.YZ
 163
 164  - Check the permissions! Actually try downloading from the, to make
 165    sure it really works.
 166
 167  - Update the HTTP redirect at the:www/putty/htaccess which points the
 168    virtual subdir `latest' at the actual latest release dir. TEST THIS
 169    ONE - it's quite important.
 170
 171  - Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
 172
 173  - Check the Docs page links correctly to the release docs. (It
 174    should do this automatically, owing to the `latest' HTTP
 175    redirect.)
 176
 177  - Check that the web server attaches the right content type to .HLP,
 178    .CNT and .CHM files, by downloading one of each and checking
 179    they're all application/octet-stream.
 180      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
 181
 182  - Run 'git push' in the website checkout, and then 'git pull' in
 183    ~/www/putty on atreus to fetch the website updates.
 184
 185  - Push the changes to PuTTY itself. Something like:
 186      git push origin master        # update the master branch
 187      git push origin --tags        # should push the new release tag
 188      git push origin :pre-0.XX     # delete the pre-release branch
 189
 190  - Run 'git push' in the putty-wishlist checkout. Then run 'git pull'
 191    in ~/pub/putty-wishlist on atreus, and update the wishlist web
 192    pages with the commands
 193      cd ~/pub/putty-wishlist/control
 194      perl bugs2html
 195
 196  - Check over the web site to make sure all the changes to wishlist
 197    and main web pages are present and correct.
 198
 199  - Run webupdate, so that all the changes on atreus propagate to
 200    chiark. Important to do this _before_ announcing that the release
 201    is available.
 202
 203  - After running webupdate, run update-rsync on chiark and verify that
 204    the rsync mirror package (~/ftp/putty-website-mirror) contains a
 205    subdirectory for the new version and mentions it in its .htaccess.
 206
 207  - Announce the release!
 208     + Construct a release announcement email whose message body is the
 209       announcement written above, and which includes the following
 210       headers:
 211        * Reply-To: <putty@projects.tartarus.org>
 212        * Subject: PuTTY X.YZ is released
 213     + Mail that release announcement to
 214       <putty-announce@lists.tartarus.org>.
 215     + Post it to comp.security.ssh.
 216     + Mention it in <TDHTT> on mono.
 217
 218  - Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were
 219    previously enabled.
 220
 221  - Relax (slightly).