Граф коммитов

4 Коммитов

Автор SHA1 Сообщение Дата
Simon Tatham 4d8782e74f Rework versioning system to not depend on Subversion.
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]
2014-09-24 10:33:13 +00:00
Jacob Nevins 6e2f435c7b Add versionid for index.
Also plumb in pgpkeys.but versionid.

[originally from svn r5594]
2005-04-05 18:03:13 +00:00
Simon Tatham da948bc151 Add an extra appendix to the manual containing PuTTY's (hitherto)
unwritten design principles, so would-be contributors won't have to
either read our minds or pay _very_ close attention to the code.

[originally from svn r4815]
2004-11-18 15:16:18 +00:00
Simon Tatham 5d32d4af14 Now we use Subversion, it seems excessive to have an individual $Id$
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]
2004-11-17 18:16:59 +00:00