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]

diff --git a/CHECKLST.txt b/CHECKLST.txt
index 3ef0982da0f3cbb79a9295c089b1b88ac98b50f0..bceaae6484a20e17263d0c7b918271e19f726f29 100644 (file)
--- 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-<ver> in case it's needed again