DragonFly users List (threaded) for 2005-03
Re: Version numbering for release DECISION!
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
(Ducking out now.)