ifeq "$(RELEASE)" "" set Ndate $(!builddate)
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -pe 's/(....)(..)(..)/$$1-$$2-$$3/' > date
ifneq "$(Ndate)" "" read Date date
-set Epoch 15860 # update this at every release
+set Epoch 16214 # update this at every release
ifneq "$(Ndate)" "" in . do echo $(Ndate) | perl -ne 'use Time::Local; /(....)(..)(..)/ and print timegm(0,0,0,$$3,$$2-1,$$1) / 86400 - $(Epoch)' > days
ifneq "$(Ndate)" "" read Days days
- Update the website, in a local checkout:
* Write a release file in components/releases which identifies the
- new version, its release date, a section for the Changes page,
- and a news announcement for the front page.
+ 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.
headers for those.
* Add an entry to the @releases array in control/bugs2html.
- - Build the release, by checking out the release tag:
- git checkout 0.XX
- bob . RELEASE=0.XX
+ - Make a release-candidate build from the release tag, and put the
+ build.out and build.log dfiles somewhere safe. Normally I store
+ these in an adjacent directory, so I'll run a command like
+ bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
This should generate a basically valid release directory as
- `build.out/putty', and provide link maps and sign.sh alongside that
- in build.out.
+ `build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
+ alongside that.
- - Double-check in build.log that the release was built from the right
- git commit.
+ - Double-check in build-X.YZ-rcN.log that the release was built from
+ the right git commit.
- Do a bit of checking of the release binaries:
* make sure they basically work
* test the Windows installer
* test the Unix source tarball.
- - Sign the release: in the `build.out' directory, type
+ - Sign the release: in the `build-X.YZ-rcN.out' directory, type
sh sign.sh -r putty
and enter the passphrases a lot of times.
+ - For my own safety, make the release candidate build read-only.
+ chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log
+
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.out directory:
../release.pl --version=X.YZ --upload
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-0.XX # delete the pre-release branch
+ git push origin :pre-X.YZ # delete the pre-release branch
- Run ~/adm/puttyweb.sh on atreus to update the website after all
those git pushes.
or use the \c{-1} command-line option; in any case, you should not
treat the resulting connection as secure.
-You might start seeing this message with new versions of PuTTY
-\#{XXX-REVIEW-BEFORE-RELEASE: (from 0.XX onwards)}
-where you didn't before, because it used to be possible to configure
-PuTTY to automatically fall back from SSH-2 to SSH-1. This is no
-longer supported, to prevent the possibility of a downgrade attack.
+You might start seeing this message with new versions of PuTTY (from
+0.68 onwards) where you didn't before, because it used to be possible
+to configure PuTTY to automatically fall back from SSH-2 to SSH-1.
+This is no longer supported, to prevent the possibility of a downgrade
+attack.
\H{errors-cipher-warning} \q{The first cipher supported by the server is
... below the configured warning threshold}
However, the SSH-1 protocol has many weaknesses and is no longer
considered secure; you should use SSH-2 instead if at all possible.
-\#{XXX-REVIEW-BEFORE-RELEASE:
As of 0.68, PuTTY will no longer fall back to SSH-1 if the server
-doesn't appear to support SSH-2; you must explicitly ask for SSH-1. }
+doesn't appear to support SSH-2; you must explicitly ask for SSH-1.
\S{faq-localecho}{Question} Does PuTTY support \i{local echo}?
Currently, release versions of PuTTY tools only run on Windows
systems and Unix.
-\#{XXX-REVIEW-BEFORE-RELEASE: replace following two lines with:
-As of 0.68, the supplied PuTTY executables run on versions of
-Windows from XP onwards,}
-PuTTY runs on versions of Windows from Windows 95 onwards (but not
-the 16-bit Windows 3.1; see \k{faq-win31}),
-up to and including Windows 10; and we know of no reason why PuTTY
-should not continue to work on future versions of Windows.
-\#{XXX-REVIEW-BEFORE-RELEASE: We provide 32-bit and 64-bit Windows
-executables; see \k{faq-32bit-64bit} for discussion of the
-compatibility issues around that.}
+As of 0.68, the supplied PuTTY executables run on versions of Windows
+from XP onwards, up to and including Windows 10; and we know of no
+reason why PuTTY should not continue to work on future versions of
+Windows. We provide 32-bit and 64-bit Windows executables; see
+\k{faq-32bit-64bit} for discussion of the compatibility issues around
+that.
(We used to also provide executables for Windows for the Alpha
processor, but stopped after 0.58 due to lack of interest.)
subdirectory. There are a couple of ways of building it,
including the usual \c{configure}/\c{make}; see the file \c{README}
in the source distribution. This should build you Unix
-ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, and also
+ports of Plink, PuTTY itself, PuTTYgen, PSCP, PSFTP, Pageant, and also
\i\c{pterm} - an \cw{xterm}-type program which supports the same
-terminal emulation as PuTTY. \#{XXX-REVIEW-BEFORE-RELEASE:}
-We do not yet have a Unix port of Pageant.
+terminal emulation as PuTTY.
If you don't have \i{Gtk}, you should still be able to build the
command-line tools.
run as a 64-bit application to work well, and having a 32-bit PuTTY on
a 64-bit system isn't likely to cause you any trouble.
-The 64-bit version
-\#{XXX-REVIEW-BEFORE-RELEASE (first released in 0.XX)}
-will only run if you have a 64-bit processor \e{and} a \I{64-bit
-Windows}64-bit edition of Windows (both of these things are likely to
-be true of any recent Windows PC). It will run somewhat faster (in
-particular, the cryptography will be faster, especially during link
-setup), but it will consume slightly more memory.
+The 64-bit version (first released in 0.68) will only run if you have
+a 64-bit processor \e{and} a \I{64-bit Windows}64-bit edition of
+Windows (both of these things are likely to be true of any recent
+Windows PC). It will run somewhat faster (in particular, the
+cryptography will be faster, especially during link setup), but it
+will consume slightly more memory.
If you need to use an external \i{DLL} for GSSAPI authentication, that
DLL may only be available in a 32-bit or 64-bit form, and that will
\W{http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/xp-wont-run}{\q{xp-wont-run}}
entry in PuTTY's wishlist has more details.
-\S{faq-system32}{Question} When I put
-\#{XXX-REVIEW-BEFORE-RELEASE 32-bit} PuTTY in
+\S{faq-system32}{Question} When I put 32-bit PuTTY in
\cw{C:\\WINDOWS\\\i{SYSTEM32}} on my \i{64-bit Windows} system,
\i{\q{Duplicate Session}} doesn't work.
\c Z:\sysosd>plink
\c Plink: command-line connection utility
-\c Release 0.67
+\c Release 0.68
\c Usage: plink [options] [user@]host [command]
\c ("host" can also be a PuTTY saved session name)
\c Options:
\c -P port connect to specified port
\c -l user connect with specified username
\c -batch disable all interactive prompts
+\c -proxycmd command
+\c use 'command' as local proxy
\c -sercfg configuration-string (e.g. 19200,8,n,1,X)
\c Specify the serial configuration (serial only)
\c The following options only apply to SSH connections:
\c -sshlog file
\c -sshrawlog file
\c log protocol details to a file
+\c -shareexists
+\c test whether a connection-sharing upstream exists
Once this works, you are ready to use Plink.
\c Z:\owendadmin>pscp
\c PuTTY Secure Copy client
-\c Release 0.67
+\c Release 0.68
\c Usage: pscp [options] [user@]host:source target
\c pscp [options] source [source...] [user@]host:target
\c pscp [options] -ls [user@]host:filespec
\c -hostkey aa:bb:cc:...
\c manually specify a host key (may be repeated)
\c -batch disable all interactive prompts
+\c -proxycmd command
+\c use 'command' as local proxy
\c -unsafe allow server-side wildcards (DANGEROUS)
\c -sftp force use of SFTP protocol
\c -scp force use of SCP protocol
print "endif\n\n";
@noinstcliprogs = ("noinst_PROGRAMS", "=");
- foreach $p (&prognames("XT:UT")) {
+ foreach $p (&prognames("UT")) {
($prog, $type) = split ",", $p;
push @noinstcliprogs, $prog;
}
+ @noinstallprogs = @noinstcliprogs;
+ foreach $p (&prognames("XT")) {
+ ($prog, $type) = split ",", $p;
+ push @noinstallprogs, $prog;
+ }
+ print "if HAVE_GTK\n";
+ print &splitline(join " ", @noinstallprogs), "\n";
+ print "else\n";
print &splitline(join " ", @noinstcliprogs), "\n";
+ print "endif\n\n";
%objtosrc = ();
foreach $d (&deps("X", undef, "", "/", "am")) {
\r
[Setup]\r
AppName=PuTTY\r
-AppVerName=PuTTY version 0.67\r
-VersionInfoTextVersion=Release 0.67\r
-AppVersion=0.67\r
-VersionInfoVersion=0.67.0.0\r
+AppVerName=PuTTY version 0.68\r
+VersionInfoTextVersion=Release 0.68\r
+AppVersion=0.68\r
+VersionInfoVersion=0.68.0.0\r
AppPublisher=Simon Tatham\r
AppPublisherURL=http://www.chiark.greenend.org.uk/~sgtatham/putty/\r
AppReadmeFile={app}\README.txt\r
projects / PuTTY.git / commitdiff