diff options
| -rw-r--r-- | doc/control-spec.txt | 5 | ||||
| -rw-r--r-- | doc/version-spec.txt | 7 |
2 files changed, 6 insertions, 6 deletions
diff --git a/doc/control-spec.txt b/doc/control-spec.txt index f317b368a..04bfb4259 100644 --- a/doc/control-spec.txt +++ b/doc/control-spec.txt @@ -941,9 +941,8 @@ $Id$ Action is a string, and Arguments is a series of keyword=value pairs on the same line. - Controllers who listen to these events will be assumed to want - both EXTENDED_EVENTS and VERBOSE_NAMES; see the explanations - in the USEFEATURE section command for details. + These events are always produced with EXTENDED_EVENTS and VERBOSE_NAMES; + see the explanations in the USEFEATURE section command for details. Actions for STATUS_GENERAL severity NOTICE events can be as follows: diff --git a/doc/version-spec.txt b/doc/version-spec.txt index 5db299456..5b9aeee01 100644 --- a/doc/version-spec.txt +++ b/doc/version-spec.txt @@ -32,9 +32,10 @@ All versions should be distinguishable purely by those four numbers. The status tag is purely informational, and lets you know how stable we think the release is: "alpha" is pretty unstable; "rc" is a release candidate; and no tag at all means that we have a final -release. If the tag ends with "-cvs", you're looking at a development -snapshot that came after a given release. If we *do* encounter two -versions that differ only by status tag, we compare them lexically. +release. If the tag ends with "-cvs" or "-dev", you're looking at a +development snapshot that came after a given release. If we *do* +encounter two versions that differ only by status tag, we compare them +lexically. Now, we start each development branch with (say) 0.1.1.1-alpha. The patchlevel increments consistently as the status tag changes, for |