On Sun, Dec 25, 2011 at 4:01 PM, Matthew Dillon <[email protected] > wrote:
> (2) I would like to call the release 3.0. Why? Because while > spending the last ~1-2 months tracking down the cpu bug a whole lot > of other work has gone into the kernel including major network > protocol stack work and major SMP work. My contribution to the SMP > work was to completely rewrite the 64-bit pmap, VM object handling > code, and VM fault handling code, as well as some other stuff. > > This has resulted in a phenominal improvement in concurrency and > in particular concurrent compilations or anything that takes a lot > of page faults. SMP contention was completely removed from the > page fault path and for most VM related operations, and almost > completely removed from the exec*() path. > > Other related work has continued to improve mysql and postgresql > numbers as well. > 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
