On Sun, Dec 25, 2011 at 7:13 PM, Samuel J. Greear <[email protected]> wrote:
>
>
> I am opposed to calling the next release 3.0. We have limited precedent to
> go by, having only really rolled over to one real .0 during DragonFly's
> life, but I think making the next release 3.0 would violate the precedent
> already established and begin a downhill trend going forward. 2.0 was
> released to coincide with HAMMER, which is the single de-facto
> most recognizable and largest user-facing feature and draw of DragonFly. We
> may not be able to drop a HAMMER-sized feature with every .0 release, but I
> think the precedent that 2.0 set was that .0 releases are reserved for
> major user-facing feature enhancements. While SMP performance has been
> improved dramatically recently I do not see that as a user-facing feature,
> in fact I would argue that a lack of proper MP support and performance
> should nowadays be considered a bug or serious design flaw. FreeBSD's
> reputation seems to have shifted from being the "performance" BSD to the
> "corporate-friendly" BSD. NetBSD is still the "portable" BSD and OpenBSD is
> still the "secure" BSD. It is my distinct impression that DragonFly is
> emerging as the "innovative" BSD, which I believe fits the spirit of the
> community and the release process to date. I believe reserving 3.0 for a
> feature-filled release would continue to foster this image and making the
> next release be 3.0 would run the distinct risk of our release numbers
> being seen as arbitrary rather than meaningful. I also think that this is a
> very slippery slope, unless there are well-defined criteria for a major
> version bump many will argue for a major version bump because of perceived
> (real or not) marketing benefits. I believe that making the next release of
> DragonFly BSD be 3.0 will result in these people arguing for 4.0 earlier in
> the next cycle and then 5.0 even earlier in the following cycle. A couple
> of cycles later we will find ourselves in FreeBSD's position of bumping the
> major version every year. The legacy of the project and how this will
> impact the next ten years of releases should be considered before
> arbitrarily calling the next release 3.0.
>
> Sam
>

Bah humbug, this feels like a 3.0 to me.

Tim

Reply via email to