DragonFly users List (threaded) for 2005-03
Version numbering for release DECISION!
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.
You can probably see why I am also using odd/even numbering... so
people can just glance at the number to get an idea of the relative
time frame without necessarily understanding what all the keywords
We are going to branch releases, starting with the one coming up.
However, I consider the branching of this upcoming release to be
primarily to allow the developers sand committers to get used to the
idea. I do not believe that DragonFly is quite ready to officially maintain
a release branch, but we are very close and I think we will be able to
do it starting with the release after this one.
Commits made to branches will contain bug fixes ONLY. They will not
contain any new work. I am going to be a bit hard-nosed about this...
FreeBSD often backported
NO INTENTION TO MAINTAIN PARALLEL RELEASES
I have no intention of maintaining parallel releases. e.g. FreeBSD-5
and FreeBSD-6 are parallel-maintained releases. We aren't doing that.
One reason is that, well, it doesn't work too well anyway, any time
you backport major new features things break. Another reason is that
developers wind up spending too much time in one release to the
detriment of the other, to the detriment of the project. So we aren't
going to do it.
DragonFly 1.2-RELEASE - Our next release
DragonFly 1.2-STABLE - Builds based on commits made on the release
branch after the release will be called
-STABLE, with the same version number of
DragonFly 1.3-CURRENT - After we release, the HEAD of the CVS tree
will become 1.3.
DragonFly 1.3-WORKING - And our slip tag, denoting a 'reasonably
stable version of current work' will use
the same version and be called -WORKING.
ILLEGAL NAME EXAMPLES
DragonFly 1.3-RELEASE - This is not a legal name (odd number with
release or stable designation is not
DragonFly 1.4-CURRENT - This is not a legal name (even number with
current or working designation is not
WHEN WILL WE GO TO 2.0
Not this year, probably not next year. When the system is mostly MP
safe and operatable with the BGL turned off, we will go to 2.0. I am
hoping that 3.0 will be our 'clustering supported' release. This is
tentative, of course, a fully working clustering release is 2+ years
down the line.