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
40 - putty-website/licence.html
42 Preparing to make a release
43 ---------------------------
45 Now that PuTTY is in git, a lot of the release preparation can be done
46 in advance, in local checkouts, and not pushed until the actual
47 process of _releasing_ it.
49 To begin with, before dropping the tag, make sure everything is ready
52 - First of all, go through the source (including the documentation),
53 and the website, and review anything tagged with a comment
54 containing the word XXX-REVIEW-BEFORE-RELEASE.
55 (Any such comments should state clearly what needs to be done.)
57 - Also, do some testing of the Windows version with Minefield, and
58 of the Unix version with valgrind or efence or both. In
59 particular, any headline features for the release should get a
60 workout with memory checking enabled!
62 - Double-check that we have removed anything tagged with a comment
63 containing the words XXX-REMOVE-BEFORE-RELEASE or
64 XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
65 hits in this file itself.)
67 - Now update the version numbers and the transcripts in the docs, by
68 checking out the release branch and running
71 ./release.pl --set-version=X.YZ
73 Then check that the resulting automated git commit has updated the
74 version number in the following places:
79 * putty/windows/putty.iss (four times, on consecutive lines)
81 and also check that it has reset the definition of 'Epoch' in
84 - Make the release tag, pointing at the version-update commit we just
87 - If the release is on a branch (which I expect it generally will
88 be), merge that branch to master.
90 - Write a release announcement (basically a summary of the changes
91 since the last release). Squirrel it away in
92 atreus:src/putty-local/announce-<ver> in case it's needed again
93 within days of the release going out.
95 - Update the web site, in a local checkout.
96 + Adjust front page to say 'The latest version is <ver>'.
97 + Adjust front page to add a news item.
98 + Adjust Download page to say 'The latest release version (<ver>)'.
99 + Adjust Download page to update filenames of installer and Unix
100 tarball (both in the hrefs themselves and the link text).
101 + Check over the Download page and remove any mention of
102 pre-releases, if there were any before this release. Comment out
103 the big pre-release section at the top, and also adjust the
104 sections about source archives at the bottom.
105 + Do the same on the Docs page.
106 + Adjust header text on Changelog page. (That includes changing
107 `are new' in previous version to `were new'!)
108 + .htaccess has an individual redirect for each version number. Add
111 - If there are any last-minute wishlist entries (e.g. security
112 vulnerabilities fixed in the new release), write entries for them
113 in a local checkout of putty-wishlist.
115 - Update the wishlist mechanism for the new release. This can be done
116 without touching individual items by editing the @releases array in
119 - Build the release, by checking out the release tag:
122 This should generate a basically valid release directory as
123 `build.out/putty', and provide link maps and sign.sh alongside that
126 - Double-check in build.log that the release was built from the right
129 - Do a bit of checking that the release binaries basically work,
130 report their version numbers accurately, and so on. Test the
131 installer and the Unix source tarball.
133 - Sign the release: in the `build.out' directory, type
135 and enter the passphrases a lot of times.
137 The actual release procedure
138 ----------------------------
140 Once all the above preparation is done and the release has been built
141 locally, this is the procedure for putting it up on the web.
143 - Save the link maps. Currently I keep these on atreus, in
144 src/putty-local/maps-<version>.
145 rsync -av maps-x86/ atreus:src/putty-local/maps-X.YZ
147 - Upload the entire release directory to atreus:www/putty/<version>.
148 rsync -av putty/ atreus:www/putty/X.YZ
150 - Do final checks on the release directory in its new location:
151 + verify all the signatures:
152 for i in `find . -name '*.gpg'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.gpg};; esac; done
153 + check the checksum files:
156 sha256sum -c sha256sums
157 sha512sum -c sha512sums
159 - Having double-checked the release, copy it from atreus to
160 chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
161 rsync -av putty/ chiark:ftp/putty-X.YZ
162 rsync -av putty/ the:www/putty/X.YZ
164 - Check the permissions! Actually try downloading from the, to make
165 sure it really works.
167 - Update the HTTP redirect at the:www/putty/htaccess which points the
168 virtual subdir `latest' at the actual latest release dir. TEST THIS
169 ONE - it's quite important.
171 - Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
173 - Check the Docs page links correctly to the release docs. (It
174 should do this automatically, owing to the `latest' HTTP
177 - Check that the web server attaches the right content type to .HLP,
178 .CNT and .CHM files, by downloading one of each and checking
179 they're all application/octet-stream.
180 for ext in hlp cnt chm; do curl -v http://the.earth.li/~sgtatham/putty/X.YZ/putty.$ext 2>&1 >/dev/null | grep Content-Type; done
182 - Run 'git push' in the website checkout, and then 'git pull' in
183 ~/www/putty on atreus to fetch the website updates.
185 - Push the changes to PuTTY itself. Something like:
186 git push origin master # update the master branch
187 git push origin --tags # should push the new release tag
188 git push origin :pre-0.XX # delete the pre-release branch
190 - Run 'git push' in the putty-wishlist checkout. Then run 'git pull'
191 in ~/pub/putty-wishlist on atreus, and update the wishlist web
192 pages with the commands
193 cd ~/pub/putty-wishlist/control
196 - Check over the web site to make sure all the changes to wishlist
197 and main web pages are present and correct.
199 - Run webupdate, so that all the changes on atreus propagate to
200 chiark. Important to do this _before_ announcing that the release
203 - After running webupdate, run update-rsync on chiark and verify that
204 the rsync mirror package (~/ftp/putty-website-mirror) contains a
205 subdirectory for the new version and mentions it in its .htaccess.
207 - Announce the release!
208 + Construct a release announcement email whose message body is the
209 announcement written above, and which includes the following
211 * Reply-To: <putty@projects.tartarus.org>
212 * Subject: PuTTY X.YZ is released
213 + Mail that release announcement to
214 <putty-announce@lists.tartarus.org>.
215 + Post it to comp.security.ssh.
216 + Mention it in <TDHTT> on mono.
218 - Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were