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

21 Коммитов

Автор SHA1 Сообщение Дата
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
Jacob Nevins 93d76da6da Some tweaks for Subversion and windows/ subdir.
[originally from svn r4794]
2004-11-16 23:32:57 +00:00
Simon Tatham 5d71729cdb Good grief! I should create the `htmldoc' subdir in the release tree
_before_ I create the md5sums files. I am a gibbon.

[originally from svn r4702]
2004-10-26 19:47:35 +00:00
Jacob Nevins a7c8747e0d Add bumping version number on trunk to new post-release checklist.
Also, sometimes `0.XX' is used in the docs as a placeholder for a version
number.

[originally from svn r4700]
2004-10-26 19:32:25 +00:00
Simon Tatham 4081fd7051 Reorder a couple of points on the wishlist, and also add a few
helpful chunks of `sh' to make life easier next time I make a release.

[originally from svn r4698]
2004-10-26 18:44:42 +00:00
Simon Tatham ba8f3d464b I'm instituting a policy that before every release I will grep the
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]
2004-10-15 08:16:29 +00:00
Simon Tatham 181e6fdfe1 My new rsync mirror setup might need attention when we do a new
release. Add to checklist.

[originally from svn r4441]
2004-08-11 09:04:47 +00:00
Simon Tatham d548396918 Bah! Knew there'd be _something_.
[originally from svn r3857]
2004-02-12 23:26:37 +00:00
Simon Tatham 82ac1def16 Modifications to the release procedure as a result of actually
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]
2004-02-12 19:45:45 +00:00
Jacob Nevins 0d9e99db60 Update the advice about updating the wishlist post-release
[originally from svn r3825]
2004-02-07 23:21:28 +00:00
Simon Tatham 6d7cc86470 Building source archives for previous releases has always been a
fiddly process. Let's have a magic script designed to do it right.

[originally from svn r3722]
2004-01-17 14:17:21 +00:00
Jacob Nevins 40af5d16a3 Add updating the wishlist to the Release checklist
[originally from svn r3615]
2003-12-03 22:49:32 +00:00
Simon Tatham f4a4551d5b We now mention the version number on the Download page, so I'd
better remember to change it next time :-)

[originally from svn r3528]
2003-11-03 13:59:46 +00:00
Simon Tatham 69efc93547 Hmm, that relative link wasn't too good. Try a more helpful one.
Also add to the release checklist so that I'll remember to set this
up properly in the next set of release docs...

[originally from svn r3525]
2003-10-30 10:41:59 +00:00
Simon Tatham 30497ff683 Ctrl+rightclick now pops up a context menu in Unix PuTTY and pterm.
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]
2003-04-05 16:05:00 +00:00
Simon Tatham 3880344edf Another item for the release checklist: don't forget to save the
link maps of the release binaries.

[originally from svn r3045]
2003-04-02 09:20:58 +00:00
Simon Tatham 14fa6023f1 Extra bit of pre-release fiddling for the checklist.
[originally from svn r3043]
2003-04-02 09:14:05 +00:00
Ben Harris ff507407b1 Move the 'vers' resources for Mac OS into their own file, to be shared
by the various applications.

[originally from svn r2843]
2003-02-13 12:30:10 +00:00
Ben Harris 902fbc43c2 Add constants to mac_res.r to set the binary version number.
Mention this in CHECKLST as a location where the version number has to be set.

[originally from svn r2598]
2003-01-14 19:29:18 +00:00
Simon Tatham 1bfd89d722 It's impossible to write a checklist from scratch without leaving
one or two things out of the first version.

[originally from svn r2590]
2003-01-14 15:01:18 +00:00
Simon Tatham ed2e68643c After the New Year copyright-dates fiasco, I think it's about time
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]
2003-01-14 14:19:35 +00:00