This repository has been archived by the owner on Apr 19, 2024. It is now read-only.
/
CHECKLST.txt
219 lines (169 loc) · 8.29 KB
/
CHECKLST.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
Checklists for PuTTY administrative procedures
==============================================
Locations of the licence
------------------------
The PuTTY copyright notice and licence are stored in quite a few
places. At the start of a new year, the copyright year needs
updating in all of them; and when someone sends a massive patch,
their name needs adding in all of them too.
The LICENCE file in the main source distribution:
- putty/LICENCE
The resource files:
- putty/windows/pageant.rc
+ the copyright date appears twice, once in the About box and
once in the Licence box. Don't forget to change both!
- putty/windows/puttygen.rc
+ the copyright date appears twice, once in the About box and
once in the Licence box. Don't forget to change both!
- putty/windows/win_res.rc2
+ the copyright date appears twice, once in the About box and
once in the Licence box. Don't forget to change both!
- putty/windows/version.rc2
+ the copyright date appears once only.
- putty/unix/gtkdlg.c
+ the copyright date appears twice, once in the About box and
once in the Licence box. Don't forget to change both!
The documentation (both the preamble blurb and the licence appendix):
- putty/doc/blurb.but
- putty/doc/licence.but
The website:
- putty-website/licence.html
Preparing to make a release
---------------------------
Now that PuTTY is in git, a lot of the release preparation can be done
in advance, in local checkouts, and not pushed until the actual
process of _releasing_ it.
To begin with, before dropping the tag, make sure everything is ready
for it:
- First of all, go through the source (including the documentation),
and the website, and review anything tagged with a comment
containing the word XXX-REVIEW-BEFORE-RELEASE.
(Any such comments should state clearly what needs to be done.)
- Also, do some testing of the Windows version with Minefield, and
of the Unix version with valgrind or efence or both. In
particular, any headline features for the release should get a
workout with memory checking enabled!
- Double-check that we have removed anything tagged with a comment
containing the words XXX-REMOVE-BEFORE-RELEASE or
XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
hits in this file itself.)
- Now update version numbers in
* putty/LATEST.VER
* putty/windows/putty.iss (four times, on consecutive lines)
* putty/doc/pscp.but (and make sure the rest of the transcript is
up to date)
* putty/doc/plink.but (likewise)
- Reset the epoch used for the $(Days) value computed in Buildscr for
the Windows binary version resource. It's probably not a good idea
to set it to _today_ (since it might clash with the zero-valued
field used in actual releases), so perhaps we should start it 1000
days before the release date so as to have a largish number
recognisable as being the right kind of thing by its order of
magnitude. So, do this:
perl -e 'printf "%d\n", time/86400 - 1000'
and then substitute the resulting value into the definition of
'Epoch' in Buildscr.
- Commit those version number and epoch changes (on the appropriate
branch, of course!), and then make the release tag pointing at the
resulting commit.
- If the release is on a branch (which I expect it generally will
be), merge that branch to master.
- Write a release announcement (basically a summary of the changes
since the last release). Squirrel it away in
atreus:src/putty-local/announce-<ver> in case it's needed again
within days of the release going out.
- Update the web site, in a local checkout.
+ Adjust front page to say 'The latest version is <ver>'.
+ Adjust front page to add a news item.
+ Adjust Download page to say 'The latest release version (<ver>)'.
+ Adjust Download page to update filenames of installer and Unix
tarball (both in the hrefs themselves and the link text).
+ Check over the Download page and remove any mention of
pre-releases, if there were any before this release. Comment out
the big pre-release section at the top, and also adjust the
sections about source archives at the bottom.
+ Do the same on the Docs page.
+ Adjust header text on Changelog page. (That includes changing
`are new' in previous version to `were new'!)
+ .htaccess has an individual redirect for each version number. Add
a new one.
- If there are any last-minute wishlist entries (e.g. security
vulnerabilities fixed in the new release), write entries for them
in a local checkout of putty-wishlist.
- Update the wishlist mechanism for the new release. This can be done
without touching individual items by editing the @releases array in
control/bugs2html.
- Build the release, by checking out the release tag:
git checkout 0.XX
bob . RELEASE=0.XX
This should generate a basically valid release directory as
`build.out/putty', and provide link maps and sign.sh alongside that
in build.out.
- Double-check in build.log that the release was built from the right
git commit.
- Do a bit of checking that the release binaries basically work,
report their version numbers accurately, and so on. Test the
installer and the Unix source tarball.
- Sign the release: in the `build.out' directory, type
sh sign.sh -r putty
and enter the passphrases a lot of times.
The actual release procedure
----------------------------
Once all the above preparation is done and the release has been built
locally, this is the procedure for putting it up on the web.
- Save the link maps. Currently I keep these on atreus, in
src/putty-local/maps-<version>.
- Upload the entire release directory to atreus:www/putty/<version>.
- Do final checks on the release directory in its new location:
+ verify all the signatures:
for i in `find . -name '*.gpg'`; do case $i in *sums*) gpg --verify $i;; *) gpg --verify $i ${i%%.gpg};; esac; done
+ check the checksum files:
md5sum -c md5sums
sha1sum -c sha1sums
sha256sum -c sha256sums
sha512sum -c sha512sums
- Having double-checked the release, copy it from atreus to
chiark:ftp/putty-<ver> and to the:www/putty/<ver>.
- Check the permissions! Actually try downloading from the, to make
sure it really works.
- Update the HTTP redirect at the:www/putty/htaccess which points the
virtual subdir `latest' at the actual latest release dir. TEST THIS
ONE - it's quite important.
- Update the FTP symlink (chiark:ftp/putty-latest -> putty-<ver>).
- Check the Docs page links correctly to the release docs. (It
should do this automatically, owing to the `latest' HTTP
redirect.)
- Check that the web server attaches the right content type to .HLP,
.CNT and .CHM files.
- Run 'git push' in the website checkout, and then 'git pull' in
~/www/putty on atreus to fetch the website updates.
- Push the changes to PuTTY itself. Something like:
git push origin master # update the master branch
git push origin --tags # should push the new release tag
git push origin :pre-0.XX # delete the pre-release branch
- Run 'git push' in the putty-wishlist checkout. Then run 'git pull'
in ~/pub/putty-wishlist on atreus, and update the wishlist web
pages with the commands
cd ~/pub/putty-wishlist/control
perl bugs2html
- Check over the web site to make sure all the changes to wishlist
and main web pages are present and correct.
- Run webupdate, so that all the changes on atreus propagate to
chiark. Important to do this _before_ announcing that the release
is available.
- After running webupdate, run update-rsync on chiark and verify that
the rsync mirror package (~/ftp/putty-website-mirror) contains a
subdirectory for the new version and mentions it in its .htaccess.
- Announce the release!
+ Construct a release announcement email whose message body is the
announcement written above, and which includes the following
headers:
* Reply-To: <putty@projects.tartarus.org>
* Subject: PuTTY X.YZ is released
+ Mail that release announcement to
<putty-announce@lists.tartarus.org>.
+ Post it to comp.security.ssh.
+ Mention it in <TDHTT> on mono.
- Edit ~/adm/puttysnap.sh to disable pre-release builds, if they were
previously enabled.
- Relax (slightly).