1 Checklists for PuTTY administrative procedures
2 ==============================================
4 Going into pre-release stabilisation
5 ------------------------------------
7 When we begin to work towards a release and want to enabling
8 pre-releases on the website:
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
17 - Edit ~/adm/puttysnap.sh on my build machine to set $prerelver correctly.
19 - Edit ~/adm/puttysnap.sh on the master machine to enable pre-release
20 builds, by changing the 'if false' to 'if true'.
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'.)
27 Preparing to make a release
28 ---------------------------
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.
34 To begin with, before dropping the tag, make sure everything is ready
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.)
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!
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.)
52 - Now update the version numbers and the transcripts in the docs, by
53 checking out the release branch and running
56 ./release.pl --version=X.YZ --setver
58 Then check that the resulting automated git commit has updated the
59 version number in the following places:
64 * putty/windows/putty.iss (four times, on consecutive lines)
66 and also check that it has reset the definition of 'Epoch' in
69 - Make the release tag, pointing at the version-update commit we just
72 - If the release is on a branch (which I expect it generally will
73 be), merge that branch to master.
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.
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
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
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
96 * Add an entry to the @releases array in control/bugs2html.
98 - Build the release, by checking out the release tag:
101 This should generate a basically valid release directory as
102 `build.out/putty', and provide link maps and sign.sh alongside that
105 - Double-check in build.log that the release was built from the right
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.
116 - Sign the release: in the `build.out' directory, type
118 and enter the passphrases a lot of times.
120 The actual release procedure
121 ----------------------------
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.
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
130 - Check that downloads via version-numbered URLs all work:
131 ../release.pl --version=X.YZ --precheck
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 .
137 - Now verify that downloads via the 'latest' URLs are all redirected
139 ../release.pl --version=X.YZ --postcheck
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
152 - Run ~/adm/puttyweb.sh on atreus to update the website after all
155 - Check that the unpublished website on atreus looks sensible.
157 - Run webupdate, so that all the changes on atreus propagate to
158 chiark. Important to do this _before_ announcing that the release
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.
165 - Announce the release!
166 + Construct a release announcement email whose message body is the
167 announcement written above, and which includes the following
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.
176 - Edit the master ~/adm/puttysnap.sh to disable pre-release builds,
177 if they were previously enabled.