CHECKLST.txt

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