I had been indecisive about whether the definitions and calls of
store_cutbuffer and retrieve_cutbuffer should be compiled out
completely in GTK-without-X mode, or whether the definitions should be
left in as stubs and the calls still present. retrieve_cutbuffer ended
up with a definition but no call in that mode.
It was only an unused-function warning, but -Werror promoted it to an
error. Fixed by making up my mind: now the functions are completely
absent, and so are the calls to them.
Notable changes:
- mentioned ASan, which now seems to be good enough to take over from
valgrind as my first-choice memory debugging tool
- release announcements now live in putty-aux
- a couple of clarifications of which directory to be in for which
commands, and adjusted relative paths appropriately
- remove obsolete mention of entering the GPG release key passphrase
numerous times (that was for GPG 1, without gpg-agent)
- remind myself that in the final signing procedure, you have to undo
the chmod you did for safety a couple of weeks earlier!
In recent releases we've taken to making the actual release build (or
rather, candidates for it) ahead of time so that we can do some
slightly more thorough last-minute testing of the exact binaries that
we're going to release to everyone. It's time I actually wrote that
procedure down in the checklist, so that I remember what it is.
In particular, we had the idea that we should not properly GPG-sign
the release until the last moment, and use the presence of a set of
full GPG signatures as a means of distinguishing the real release
build from an RC that accidentally got out into the wild somehow. This
checklist update formalises that too, and documents the method I used
of ensuring the binaries weren't tampered with between RC building and
release signing (by making a signature on just the sha512sums). I also
include in this commit an extra command-line option to sign.sh to make
that preliminary signature step more convenient.
Previously, it demanded that your checkout was in a state where you
had run autoconf but not configure; so if you previously did have a
Makefile then you had to 'make distclean' to remove it, whereas if you
previously had no generated files at all (e.g. starting from a
completely clean checkout) then you had to run mkfiles.pl and
mkauto.sh to generate 'configure'.
This is obviously confusing, and moreover, the dependence on prior
generated files is fragile and prone to them having been generated
wrong. Adjusted the script so that it uses 'git archive' to get a
clean directory containing only the version-controlled files, and then
runs scripts itself to get that directory into the state it wants.
The rewritten bugs2html.py in the wishlist repository no longer needs
me to manually maintain a mapping between releases and version control
- and the one thing I forgot was to remove the reminder in the release
checklist telling me to keep that mapping up to date :-)
Our recommended package for website mirrors doesn't need one any more,
because its latest.html links already point directly to the numbered
release subdirectory. Hence, remove the release-checklist instruction
to check the mirror package's .htaccess, and replace it with an
instruction to check the links in latest.html instead.
The main tartarus.org host has changed since the last release, so we
now have to upload things to somewhere different. Updated the release
automation in release.pl, and all the mentions of atreus in the manual
checklist too.
These reflect the fact that I'm increasingly preferring to make a
release-candidate build a few days in advance of the actual release,
and give the team time to do a bit of testing on it before putting it
up on the live website. Hence, I can't _quite_ fill in everything in
the website announcement ahead of time - the release date has to wait
until we know what it is, which means I need to have 'now fill in the
release date' as part of the go-live checklist.
Also, I've provided a better bob command for doing a release build
(putting it somewhere safe to begin with, rather than leaving it
precariously in my normal build directory). And while I'm here, I've
standardised all my placeholder version numbers to X.YZ; previously
half of them said 0.XX :-)
I've now made a new section about how to turn on pre-release mode,
because although it's been carefully made trivial within the website
repo itself, there are still several things in other places I need to
edit.
Also added a note to myself to turn off nightly pre-release builds
after the release has gone out. I found on a previous occasion that my
build machine had been building them for months after they were
needed, which was harmless to the website but a waste of CPU!
Now we have licence.pl, it seems to me to make very good sense to have
it generate the Halibut form(s) of the licence and copyright year as
well as the source-code forms.
As a result, I believe _no_ copies of the licence text or copyright
date exist any more except for the master one in LICENCE - so I can
completely remove the checklist section about all the places to update
it, because there's only one. Hooray!
Now all the uses of the licence text or the short copyright notice get
it from a new header "licence.h", which in turn is built by a Perl
script licence.pl invoked by mkfiles.pl, using LICENCE itself as the
source.
Hence, I can completely remove a whole section from the list of
licence locations in CHECKLST.txt :-)
This makes the About and Licence boxes copy-and-pasteable, similarly
to what I've just done on Unix.
(But unlike on the Unix side, here I haven't touched the host key
prompt dialog, because that's a standard Windows MessageBox and not
easy to mess around with. Plus, in any case, you can already hit ^C to
copy the whole text out of a MessageBox. Same goes for the PGP
fingerprints dialog.)
As a side effect, several copies of the copyright notice and licence
text have moved from .rc files into C source. I've updated
CHECKLST.txt, but they won't stay there for long.
Half the release checklist has changed recently, what with me
completely reworking the website and also writing all this release
automation. I think these are all the checklist changes needed now the
dust has settled, though of course when I do the next actual release I
expect there'll turn out to be something I missed...
I've added a few sample shell commands in the upload procedure (mostly
so that I don't have to faff about remembering how rsync trailing
slashes work every time), and also written a script called
'release.pl', which automates the updating of the version number in
all the various places it needs to be done and also ensures the PSCP
and Plink transcripts in the docs will match the release itself.
I spotted that I've been checking that old-style Windows Help files
were delivered with content-type "application/octet-stream", but not
also checking the same thing about the marginally newer .CHM ones. (Or
at least not writing it down in the wishlist; I think I did actually
check on at least one occasion.)
sign.sh's command-line syntax has changed, so I've updated the sample
command line in CHECKLST as well. Also the file extensions of the
signatures have changed, so I've updated the pre-release verification
command line in CHECKLST too.
The -F option is no longer needed to bob in this situation; that
hasn't been the directory I keep release announcements in for a long
time; the Docs page needs adjusting for pre-release retirement as well
as the Downloads page.
Mostly I'm rearranging things because of the new workflows that git
makes available - it's now possible (and indeed sensible) to prepare a
lot of stuff in a fairly relaxed manner in local checkouts, and then
the process of going live with the release has a lot less manual
writing of stuff and a lot more mechanical 'git push' and running of
update scripts.
However, there's one new item that was actually missed off the
previous checklist: turning off nightly pre-release builds after
making the release they were a pre-release of. Ahem.
I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).
While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.
I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.
[originally from svn r10262]
announcement email without a subject line, so I'm reorganising the
announcement entry in the checklist in the hope that it'll make it
harder for me to get that one wrong in future!
[originally from svn r9371]
website _wasn't_ missing - I just looked straight past it somehow.
Fold the two versions together into one more complete than either.
[originally from svn r9206]
- for 'ixion' read 'atreus' throughout
- the signature-checking commands needed minor modifications to cope
with more *sums files
- stated a few things explicitly which were previously implied, in
case the next inter-release gap is also long enough for me to
forget them.
[originally from svn r9205]
the release directory into a _subdirectory_ of the main build.out,
and delivers the link maps and sign.sh alongside it. That simplifies
both the nightly snapshot cron job (which now doesn't have to
carefully move the maps out of the release directory or go looking
in strange places for sign.sh) and my release procedure (for much
the same reasons).
[originally from svn r7258]
- Now we've fixed `win-versioninfo', choose some sensible outcomes from
the installer's comparisons of binary version numbers. Also, give the
installer _itself_ a matching binary version.
In particular, without this change, it would not have been possible
to downgrade PuTTY -- it would have silently left the "newer" files in
place. Now it will make some fuss, but permit it.
- Also remove descriptions from shortcuts, on the grounds that the
binaries have embedded descriptions now. (Although I've not checked
whether those are actually visible in the Start Menu.)
- At the request of various people (e.g., PJB), add flags so that if
files are in use at the time the (un)installer is run, replacement is
deferred to the next restart. (The user may be prompted to restart,
which isn't ideal; see comments).
This is supposed to make centrally-pushed silent upgrades more robust.
- Note some limitations of the installer.
[originally from svn r6585]
a VERSIONINFO resource. The versioning scheme is described in
windows/version.rc2.
Some .rc files are now #included in others. In order to keep MSVC
project files working, these have been renamed to .rc2; there may exist
a better solution.
(This checkin also includes the documentation tweak missing from r6367.)
Testing performed:
- MinGW (cross-compiler): works
- VC nmake: works (tested with VC6)
- VC project files: builds with VERSIONINFO resource (no VER variable though)
- Borland: an old version of this patch was tested with it and more or
less worked, except that some of the VERSIONINFO strings were apparently
not terminated properly. Not attempted to work around this.
- LCC: not tested. Some fixes are in there from the last time we tried
this, but then the build ultimately failed and I haven't tried this
since that was fixed.
- Dev-C++: untested. (Haven't done anything special.)
- Unix Gtk/autoconf Makefiles work as before.
[originally from svn r6374]
[r6367 == f86ad059db]
[this svn revision also touched putty-wishlist]
release announcement, because people reply directly to the
putty-announce mail. I should remember to set a Reply-To header next
time.
[originally from svn r5613]
a few things that will faze whatever we're using currently (2.0.19 or
thereabouts?), but nothing desperately modern. (NB, the 0.57 putty.iss works
fine with 5.0.8 and the installer is even 40k smaller.)
Notable changes:
- Uninstallation now runs a variant of `putty -cleanup'. The variance is
only in the text displayed; the user is still prompted, and the default
action is (now) "keep" in both cases.
- Optionally add an icon in the Quick Launch bar.
- Make desktop item optionally for all users. (not tested)
- "Create a Start Menu group" now handled via IS' own mechanism.
[originally from svn r5423]
line for every single .but file at the bottom of each page of the
HTML PuTTY docs. However, we can't _always_ replace that with a
single SVN revision, because there isn't always one available (SVN
still allows mixed working copies in which some files are
deliberately checked out against a different revision).
Hence, here's a mechanism for doing better. It uses `svnversion .'
to determine _whether_ a single revision number adequately describes
the current directory, and replaces all the version IDs with that if
so. If it can't do that, it uses the version IDs as before.
Also, this allows an explicit version string to be passed on the
make command line which will override _both_ these possibilities, so
that release documentation can be clearly labelled with the release
version number.
[originally from svn r4804]
