Schedule for releases

mdf at FreeBSD.org mdf at FreeBSD.org
Tue Dec 21 17:47:09 UTC 2010


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.

Thanks,
matthew


More information about the freebsd-arch mailing list