Re: Version numbering for release DECISION!

[Walter <walter@xxxxxxx>]

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