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
220
221
222
223
|
Checklists for PuTTY administrative procedures
==============================================
Going into pre-release stabilisation
------------------------------------
When we begin to work towards a release and want to enable
pre-releases on the website:
- Make a branch whose tip will be the current state of the
pre-release. Regardless of whether the branch is from master or
from a prior release branch, the name of the branch must now be in
the form 'pre-X.YZ', or else the website will fail to link to it
properly in gitweb and the build script will check out the wrong
thing.
- Edit ~/adm/puttysnap.sh on my build machine to set $prerelver correctly.
- Edit ~/adm/puttysnap.sh on the master machine to enable pre-release
builds, by changing the 'if false' to 'if true'.
- Put the website into pre-release mode, by defining prerel_version()
in components/Base.mc to return the upcoming version number. Also
add a news announcement in components/news. (Previous naming
convention has been to name it in the form 'X.YZ-pre.mi'.)
Things to do during the branch-stabilisation period:
- 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.)
- Do some testing of the Windows version with Minefield (you can
build a Minefield version using 'bob . XFLAGS=-DMINEFIELD'), and of
the Unix version with valgrind and/or Address Sanitiser. In
particular, any headline features for the release should get a
workout with memory checking enabled!
Making a release candidate build
--------------------------------
- Make a directory to hold all the release paraphernalia. I usually
call it ~/src/putty/X.YZ (where X.YZ will stand throughout for the
version number).
- Inside that directory, clone the PuTTY git repository to a
subdirectory ~/src/putty/X.YZ/putty. Here you can make release-
related commits and tags tentatively, and keep them out of the way
of any 'git push' you might still be doing in other checkouts.
- 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 the version numbers and the transcripts in the docs, by
checking out the release branch in the release-specific checkout
and running
./release.pl --version=X.YZ --setver
Then check that the resulting automated git commit has updated the
version number in the following places:
* putty/LATEST.VER
* putty/doc/plink.but
* putty/doc/pscp.but
and also check that it has reset the definition of 'Epoch' in
Buildscr.
- Make the release tag, pointing at the version-update commit we just
generated.
- If the release is on a branch (which I expect it generally will
be), merge that branch to master.
- Make a release-candidate build from the release tag, and put the
build.out and build.log files somewhere safe. Normally I store
these inside the ~/src/putty/X.YZ directory, alongside the git
checkout at ~/src/putty/X.YZ/putty, so I'll sit in that checkout
directory and run a command like
bob -o ../build-X.YZ-rcN.out -l ../build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
This should generate a basically valid release directory as
`build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
alongside that.
- Double-check in build-X.YZ-rcN.log that the release was built from
the right git commit.
- Make a preliminary gpg signature, but don't run the full release-
signing procedure. (We use the presence of a full set of GPG
signatures to distinguish _abandoned_ release candidates from the
one that ended up being the release.) In the 'build.X.YZ-rcN.out'
directory, run
sh sign.sh -r -p putty
which will generate a clearsigned file called
sha512sums-preliminary.gpg _outside_ the 'putty' subdirectory.
- For my own safety, make the release candidate build read-only.
chmod -R a-w build-X.YZ-rcN.{out,log}
- Now do some checking of the release binaries, and pass them to the
rest of the team to do some as well. Do at least these things:
* make sure they basically work
* check they report the right version number
* if there's any easily observable behaviour difference between
the release branch and master, arrange to observe it
* test the Windows installer
* test the Unix source tarball.
Preparing to make the release
-----------------------------
- Write a release announcement (basically a summary of the changes
since the last release). Check the draft version into the putty-aux
repository, so the whole team can help wordsmith it if they want to.
- Update the website, in a local checkout:
* Write a release file in components/releases which identifies the
new version, a section for the Changes page, and a news
announcement for the front page.
+ The one thing this can't yet contain is the release date;
that has to be put in at the last minute, when the release
goes live. Fill in 'FIXME', for the moment.
* Disable the pre-release sections of the website (if previously
enabled), by editing prerel_version() in components/Base.mc to
return undef.
- Update the wishlist, in a local checkout:
* If there are any last-minute wishlist entries (e.g. security
vulnerabilities fixed in the new release), write entries for
them.
* If any other bug fixes have been cherry-picked to the release
branch (so that the wishlist mechanism can't automatically mark
them as fixed in the new release), add appropriate Fixed-in
headers for those.
- Sign the release in full. In the `build-X.YZ-rcN.out' directory,
re-verify that the preliminary signed checksums file has a correct
signature on it and also matches the files you're about to sign for real:
gpg -d sha512sums-preliminary.gpg | (cd putty; grep -vF ' (installer version)' | grep . | sha512sum -c)
If the combined output of that pipeline reports both a good
signature (from the release key) and a successful verification of
all the sha512sums, then all is well and you can do the full
signing (not forgetting that the directory will have been readonly
during the last-minute testing period):
chmod -R u+w putty
sh sign.sh -r putty # and enter the release key passphrase
chmod -R a-w putty
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.
- Make a final adjustment to your local website changes, filling in
the release date in components/releases/X.YZ.mi.
- Upload the release itself and its link maps to everywhere it needs
to be, by running this in the build-X.YZ-rcN.out directory:
../putty/release.pl --version=X.YZ --upload
- Check that downloads via version-numbered URLs all work:
../putty/release.pl --version=X.YZ --precheck
If this has trouble accessing chiark's ftp server, that is
unfortunately normal; add --no-ftp and try again.
- Switch the 'latest' links over to the new release:
* Update the HTTP redirect at the:www/putty/htaccess .
* Update the FTP symlink at chiark:ftp/putty-latest .
- Now verify that downloads via the 'latest' URLs are all redirected
correctly and work:
../putty/release.pl --version=X.YZ --postcheck
- Push all the git repositories:
* run 'git push' in the website checkout
* run 'git push' in the wishlist checkout
* push from the main PuTTY checkout. Typically this one will be
pushing both the release tag and an update to the master branch,
plus removing the pre-release branch, so you'll want some
commands along these lines:
git push origin master # update the master branch
git push origin --tags # should push the new release tag
git push origin :pre-X.YZ # delete the pre-release branch
- Run ~/adm/puttyweb.sh on thyestes to update the website after all
those git pushes.
- Check that the unpublished website on thyestes looks sensible.
- Run webupdate, so that all the changes on thyestes 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 that the links from its
latest.html point into that subdirectory.
- 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 the master ~/adm/puttysnap.sh to disable pre-release builds,
if they were previously enabled.
- Relax (slightly).
|
