Version numbering for release DECISION!

[Walter]

Matthew Dillon wrote:
    I've decided on a version numbering scheme.  Sorry, dates are out.
    As much as dates are interesting, they create problems when dealing 
    with multiple branches.  More importantly, they do not impart the
    same sense of progress that real version numbers impart and, even
    more importantly, all kernels are moving targets and tagged with
    their build dates anyway so having a release date AND a build date 
    is simply too confusing.

    EVEN numbers denote releases.  e.g. 1.0, 1.2, 1.4, 1.6
    ODD numbers denote work-in-progress.  e.g. 1.1, 1.3, 1.5, 1.7
    -CURRENT	Will indicate a build based on the head of the CVS tree.

    -WORKING	Will indicate a build baesd on our current stable tag

		I am going to rename the tag from DragonFly_Stable to
		DragonFly_Working to avoid confusion, but not today.  This
		tag has turned out to be quite important because it allows
		developers to stay reasonably up to date but take less
		risk then the people running CURRENT.
    -RELEASE	Will indicate a build based on a release branch.

    -STABLE	Will indicate a build based on a post-release branch.
Drive-by, mainly ignorant, lurker question / suggestion here:

Instead of calling the current stable development tag WORKING
and the lastest patched release version STABLE, why not leave
STABLE for the former, and use something like UPDATED for the
latter?
(Ducking out now.)

Walter