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