Version numbering for release DECISION!

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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
    mean.

				    BRANCHING

    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.

				    EXAMPLES

    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 
				  the release.

    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
				  allowed)

    DragonFly 1.4-CURRENT	- This is not a legal name (even number with
				  current or working designation is not
				  allowed).

				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.

						-Matt