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

[Tim Darby <t+dfbsd@xxxxxxxxxxxx>]

--14dae9341273af97f404b4f687af
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Dec 25, 2011 at 7:13 PM, Samuel J. Greear <sjg@evilcode.net> 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

--14dae9341273af97f404b4f687af
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sun, Dec 25, 2011 at 7:13 PM, Samuel J. Greea=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:sjg@evilcode.net";>sjg@evilcode.ne=
t</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div class=3D"im"><div><br></div></div><div>I am=
 opposed to calling the next release 3.0. We have limited precedent to go b=
y, having only really rolled over to one real .0 during DragonFly&#39;s lif=
e, but I think making the next release 3.0 would violate the precedent alre=
ady established and begin a downhill trend going forward. 2.0 was released =
to coincide with HAMMER, which is the single de-facto most=A0recognizable=
=A0and largest user-facing feature and draw of DragonFly. We may not be abl=
e to drop a HAMMER-sized feature with every .0 release, but I think the pre=
cedent 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 consid=
ered a bug or serious design flaw. FreeBSD&#39;s reputation seems to have s=
hifted from being the &quot;performance&quot; BSD to the &quot;corporate-fr=
iendly&quot; BSD. NetBSD is still the &quot;portable&quot; BSD and OpenBSD =
is still the &quot;secure&quot; BSD. It is my distinct impression that Drag=
onFly is emerging as the &quot;innovative&quot; BSD, which I believe fits t=
he spirit of the community and the release process to date. I believe reser=
ving 3.0 for a feature-filled release would continue to foster this image a=
nd making the next release be 3.0 would run the distinct risk of our releas=
e 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 pe=
rceived (real or not) marketing benefits. I believe that making the next re=
lease of DragonFly BSD be 3.0 will result in these people arguing for 4.0 e=
arlier 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&#39;s position o=
f bumping the major version every year. The legacy of the project and how t=
his will impact the next ten years of releases should be considered before =
arbitrarily calling the next release 3.0.</div>


<div><br></div><div>Sam</div></div>
</blockquote></div><br><div><font><font face=3D"trebuchet ms,sans-serif">Ba=
h humbug, this feels like a 3.0 to me.<br clear=3D"all"></font></font><div>=
<br></div>Tim<br></div>

--14dae9341273af97f404b4f687af--