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]
PuTTY source for the word XXX-REMOVE-BEFORE-RELEASE, and not release
until I've got rid of all of them. Hence, here's an addition to the
release checklist which will remind me to do so.
I don't want this mechanism to seriously inhibit a release by being
a placeholder for a large piece of work we might never get round to.
It should be used only in cases where it's _simple_ to change the
offending code: for example, a performance-impacting diagnostic
might be invaluable while testing nightly snapshots but wouldn't
want to slow down everyone's next release, and it's easy to get rid
of on release day.
[originally from svn r4623]
trying to _follow_ it for the first time :-) And also due to the
fact that it now needs to mention the Unix source tarball as well.
[originally from svn r3853]
This menu is not yet fully populated, but it has an About box (yet
another licence location :-/ ) and supports the new configurable
specials menu (thus making Unix PuTTY do one tiny thing which
OpenSSH-in-a-pterm can't :-).
[originally from svn r3062]
we had one or two official checklists. This file lists the locations
of _all_ the copies of the licence and the copyright dates, all the
files in CVS which need to know the current version number, and also
lays out the release procedure since I always find it terribly
fiddly to do it all in the right order.
PLEASE KEEP THESE LISTS UP TO DATE, people! Anyone adds a new copy
of the licence or the copyright notice, shout about it in here.
Likewise any file that needs to know the current release number and
can't get away with referencing LATEST.VER.
[originally from svn r2589]
