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