Re: FreeBSD has serious problems with focus, longevity,

On 01/18/2012 11:46, John Kozubik wrote:
> - mark 9 as the _only_ production release

While I understand your motivation, I am not sure this is a workable
goal when combined with the goal that others have expressed of longer
timelines for the support of a given branch. Speaking from personal
experience, once a service is released on a given platform the costs of
migration can be significant. And if what I have is working well and
only needs the occasional bug/security fix my motivations for migration
are near zero. So the tradeoffs then become more frequent major releases
to get new features, vs. longer support for a given release branch.

Let's take 5 years as a reasonable time period for supporting a branch.
Waiting that long between major releases would significantly stifle the
ability to add new features that require breaks to the [AK][BP]I. It
would also inhibit our ability to do revolutionary architectural changes
such as moving to clang as the primary supported compiler.

What I've proposed instead is a new major release every 2 1/2 years,
where the new release coincides with the EOL of the oldest production
release. That way we have a 5-year cycle of support for each major
branch, and no more than 2 production branches extant at one time.

History tells us that 2 production branches is a goal we can achieve,
with the focus shifting more heavily towards only bug/security fixes in
the oldest branch after the new production release branch is cut. If we
combine that with the ideas that are being put forward about teams that
"own" a production branch, and a more frequent stripped-down release
process, I think this is a very workable model.

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"