Matt Dillon [interview] decided on an official version numbering scheme for DragonFlyBSD releases. First ruling out the usage of dates in each release, he settled on using odd numbers to denote a work in progress, and even numbers to denote releases. For example, 1.0, 1.2, 1.4, and so on would be considered releases, whereas 1.1, 1.3, 1.5, and so on would be considered works in progress.
Four tags will also be used, -CURRENT, -WORKING, -RELEASE and -STABLE. The -CURRENT tag indicates "a build based on the head of the CVS tree." The -WORKING tag indicates "a build based on our current stable tag". The -RELEASE tag indicates "a build based on a release branch." And the -STABLE tag indicates "a build based on a post-release branch." Matt adds, "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." Following this scheme, the next stable release will be DragonFly 1.2-RELEASE.
From: Matthew Dillon To: kernel AT crater.dragonflybsd.org Subject: Version numbering for release DECISION! Date: Mon, 03/28/2005 - 00:16 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