Schedule for releases

[Garrett Cooper]

On Dec 21, 2010, at 9:47 AM, mdf at FreeBSD.org wrote:

> I suspect this has been discussed before but I wanted to bring it up
> again in light of my experience using FreeBSD as the base for a
> commercial product.
> 
> Commercial life cycles can be rather long.  For me, I started working
> on porting Isilon's code base to FreeBSD 7.1 in May of 2009, at the
> time knowing nothing about FreeBSD and extremely little about Isilon's
> code base.  For reference, at the time 7.1 was the most recent
> RELENG_7 branch, and CURRENT had not yet been cloned into RELENG_8.
> For various business reasons, at the time we did not want to track
> CURRENT so settled on a local svn mirror of stable/7 to make pulling
> patches easier.
> 
> Fast forward about 9 months and the merge project is complete, and
> tested, and we're all happy.  But FreeBSD has moved on a bit, with 8.1
> out any day now.  Now fast forward another 6 months, and here we are
> today, with 7.4 about to come out and EOL the stable/7 branch, and the
> product based on FreeBSD stable/7 finally hitting GA.
> 
> My point in all this is that commercial software endeavors can be
> multi-year efforts.  But the support for stable/7 is pretty low now; I
> noticed over the last year that many MFC's went to stable/8 but not
> stable/7.
> 
> So the question:
> 
> Should FreeBSD support release branches for a longer time period?  I
> am assuming that after 7.4 comes out only security fixes will be going
> into stable/7.  The difficulty with supporting the release comes
> partly because of KBI/ABI changes.  It may be that CURRENT has changed
> enough that it's just not practical to support a release that was
> initially cloned 2 1/2 years ago.
> 
> For various reasons I am hoping that the next merge project we do
> locally will be to CURRENT, because that makes staying in sync with
> FreeBSD and returning our code to the community easiest.  But making
> the business case isn't quite as simple.

	We're still stuck on 6.x to a large degree at IronPort :(... 8.x -- what's 8.x :/...?
	So yes, it would be nice to have a longer lifecycle on some releases, but I fear that the problem is most likely scalability and that FreeBSD needs more automated tests. It can also painful backporting features and bugfixes to old releases, but that's a different note that I'm sure every developer on the list is already aware of. security folks could answer this question a lot better (cperciva, simon, et all).
Thanks,
-Garrett