CHECKLST.txt

   1 Checklists for PuTTY administrative procedures
   2 ==============================================
   3
   4 Preparing to make a release
   5 ---------------------------
   6
   7 Now that PuTTY is in git, a lot of the release preparation can be done
   8 in advance, in local checkouts, and not pushed until the actual
   9 process of _releasing_ it.
  10
  11 To begin with, before dropping the tag, make sure everything is ready
  12 for it:
  13
  14  - First of all, go through the source (including the documentation),
  15    and the website, and review anything tagged with a comment
  16    containing the word XXX-REVIEW-BEFORE-RELEASE.
  17    (Any such comments should state clearly what needs to be done.)
  18
  19  - Also, do some testing of the Windows version with Minefield, and
  20    of the Unix version with valgrind or efence or both. In
  21    particular, any headline features for the release should get a
  22    workout with memory checking enabled!
  23
  24  - Double-check that we have removed anything tagged with a comment
  25    containing the words XXX-REMOVE-BEFORE-RELEASE or
  26    XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
  27    hits in this file itself.)
  28
  29  - Now update the version numbers and the transcripts in the docs, by
  30    checking out the release branch and running
  31
  32       make distclean
  33       ./release.pl --version=X.YZ --setver
  34
  35    Then check that the resulting automated git commit has updated the
  36    version number in the following places:
  37
  38     * putty/LATEST.VER
  39     * putty/doc/plink.but
  40     * putty/doc/pscp.but
  41     * putty/windows/putty.iss (four times, on consecutive lines)
  42
  43    and also check that it has reset the definition of 'Epoch' in
  44    Buildscr.
  45
  46  - Make the release tag, pointing at the version-update commit we just
  47    generated.
  48
  49  - If the release is on a branch (which I expect it generally will
  50    be), merge that branch to master.
  51
  52  - Write a release announcement (basically a summary of the changes
  53    since the last release). Squirrel it away in
  54    atreus:src/putty-local/announce-<ver> in case it's needed again
  55    within days of the release going out.
  56
  57  - Update the website, in a local checkout:
  58     * Write a release file in components/releases which identifies the
  59       new version, its release date, a section for the Changes page,
  60       and a news announcement for the front page.
  61     * Disable the pre-release sections of the website (if previously
  62       enabled), by editing prerel_version() in components/Base.mc to
  63       return undef.
  64
  65  - Update the wishlist, in a local checkout:
  66     * If there are any last-minute wishlist entries (e.g. security
  67       vulnerabilities fixed in the new release), write entries for
  68       them.
  69     * If any other bug fixes have been cherry-picked to the release
  70       branch (so that the wishlist mechanism can't automatically mark
  71       them as fixed in the new release), add appropriate Fixed-in
  72       headers for those.
  73     * Add an entry to the @releases array in control/bugs2html.
  74
  75  - Build the release, by checking out the release tag:
  76      git checkout 0.XX
  77      bob . RELEASE=0.XX
  78    This should generate a basically valid release directory as
  79    `build.out/putty', and provide link maps and sign.sh alongside that
  80    in build.out.
  81
  82  - Double-check in build.log that the release was built from the right
  83    git commit.
  84
  85  - Do a bit of checking of the release binaries:
  86     * make sure they basically work
  87     * check they report the right version number
  88     * if there's any easily observable behaviour difference between
  89       the release branch and master, arrange to observe it
  90     * test the Windows installer
  91     * test the Unix source tarball.
  92
  93  - Sign the release: in the `build.out' directory, type
  94      sh sign.sh -r putty
  95    and enter the passphrases a lot of times.
  96
  97 The actual release procedure
  98 ----------------------------
  99
 100 Once all the above preparation is done and the release has been built
 101 locally, this is the procedure for putting it up on the web.
 102
 103  - Upload the release itself and its link maps to everywhere it needs
 104    to be, by running this in the build.out directory:
 105       ../release.pl --version=X.YZ --upload
 106
 107  - Check that downloads via version-numbered URLs all work:
 108       ../release.pl --version=X.YZ --precheck
 109
 110  - Switch the 'latest' links over to the new release:
 111     * Update the HTTP redirect at the:www/putty/htaccess .
 112     * Update the FTP symlink at chiark:ftp/putty-latest .
 113
 114  - Now verify that downloads via the 'latest' URLs are all redirected
 115    correctly and work:
 116       ../release.pl --version=X.YZ --postcheck
 117
 118  - Push all the git repositories:
 119     * run 'git push' in the website checkout
 120     * run 'git push' in the wishlist checkout
 121     * push from the main PuTTY checkout. Typically this one will be
 122       pushing both the release tag and an update to the master branch,
 123       plus removing the pre-release branch, so you'll want some
 124       commands along these lines:
 125         git push origin master        # update the master branch
 126         git push origin --tags        # should push the new release tag
 127         git push origin :pre-0.XX     # delete the pre-release branch
 128
 129  - Run ~/adm/puttyweb.sh on atreus to update the website after all
 130    those git pushes.
 131
 132  - Check that the unpublished website on atreus looks sensible.
 133
 134  - Run webupdate, so that all the changes on atreus propagate to
 135    chiark. Important to do this _before_ announcing that the release
 136    is available.
 137
 138  - After running webupdate, run update-rsync on chiark and verify that
 139    the rsync mirror package (~/ftp/putty-website-mirror) contains a
 140    subdirectory for the new version and mentions it in its .htaccess.
 141
 142  - Announce the release!
 143     + Construct a release announcement email whose message body is the
 144       announcement written above, and which includes the following
 145       headers:
 146        * Reply-To: <putty@projects.tartarus.org>
 147        * Subject: PuTTY X.YZ is released
 148     + Mail that release announcement to
 149       <putty-announce@lists.tartarus.org>.
 150     + Post it to comp.security.ssh.
 151     + Mention it in <TDHTT> on mono.
 152
 153  - Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were
 154    previously enabled.
 155
 156  - Relax (slightly).