DragonFly BSD
DragonFly kernel List (threaded) for 2011-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Merry X-Mas and 3.0 release after the holidays - date not yet decided

From: John Marino <dragonflybsd@xxxxxxxxx>
Date: Mon, 26 Dec 2011 10:31:42 +0100

On 12/26/2011 4:39 AM, Samuel J. Greear wrote:
> Part of my point was that I don't think that reason, the concurrency
> work specifically, is a good reason to call a release 3.0 instead of
> 2.12 or 2.14. The only precedent we have to go by to date is 2.0, which
> was a major user-facing feature release. I feel the precedent that was
> set by that release was a very good one and that we should consider very
> hard sticking to it and the ramifications of a potential "major version
> bump because we are feeling pretty good about ourselves" precedent
> before calling this next release 3.0. But it sounds like you have
> already made up your mind.
> Sam

I think numerically this is going to be the 14th release.  I'm
sympathetic to Sam's point of view in that I think the "major"
milestones are always subjective, and that we'll be having the same
argument for DragonFly 4.0 and 5.0.

I wouldn't mind taking a page out of Emac's and Binutils handbook and
change the numbering scheme completely:
 1) Ordinal releases forever
 2) Developer branch minor number is 5

In that scheme, this next release would be DragonFly 14.0.0 and the
master would take on the number 14.5.0, and the subsequent release would
be DragonFly 15.0.0.  This idea is based off comments Sam made in IRC,
and it would take out the whole "major milestone" discussion out
forever.  I guess Linux Mint is basically doing this too.

Besides the obvious negative aspect of a numbering scheme going 2.10,
2.11, 2.13, 14.0, 14.5 ..., there might be practical impacts with
autotools.  FreeBSD 10 is in a world of hurt right now because the
"configure" script on thousands of ports have regex interpreting FreeBSD
10.0 as FreeBSD 1.  This "ordinal" scheme might see some pkgsrc
regression if the package isn't expecting double-digit major numbers but
I think that would be a fairly rare case.

I don't think this proposal will be popular, but I throw it out there as
a way to address Sam's concern and to eliminate this academic
discussion.  Doesn't DragonFly 14 sound better than DragonFly 3.0?
... or throw Roman Numerals in there for eliteness: DragonFly XIV   :)


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]