From ba8f3d464ba90f9c2ad00d0f2d7dad188d6f0de9 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Fri, 15 Oct 2004 08:16:29 +0000 Subject: [PATCH] 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] --- CHECKLST.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/CHECKLST.txt b/CHECKLST.txt index 3ef0982d..bceaae64 100644 --- a/CHECKLST.txt +++ b/CHECKLST.txt @@ -41,6 +41,9 @@ The website: Before tagging a release ------------------------ + - First of all, go through the source and remove anything tagged + with a comment containing the word XXX-REMOVE-BEFORE-RELEASE. + For a long time we got away with never checking the current version number into CVS at all - all version numbers were passed into the build system on the compiler command line, and the _only_ place @@ -82,6 +85,9 @@ This is the procedure I (SGT) currently follow (or _should_ follow :-) when actually making a release, once I'm happy with the position of the tag. + - Double-check that we have removed anything tagged with a comment + containing the word XXX-REMOVE-BEFORE-RELEASE. + - Write a release announcement (basically a summary of the changes since the last release). Squirrel it away in ixion:src/putty/local/announce- in case it's needed again