FreeBSD9 and the sheer number of problem reports

Kevin Oberman kob6558 at
Sun Feb 26 19:53:02 UTC 2012

On Sun, Feb 26, 2012 at 5:08 AM, Erich Dollansky
<erichfreebsdlist at> wrote:
> Hi,
> On Sunday 26 February 2012 19:42:55 jb wrote:
>> H <hm <at>> writes:
>> > ...
>> > it is about FreeBSD and the meaning, importance and reliability  of
>> > -RELEASE for all people
>> > ...
>> > > Still, FreeBSD has always at least one more release out there which
>> > > was hardened in real life.
>> > > ...
>> Hi,
>> I think you have a point.
>> There was a very interesting discussion on "FreeBSD and release engineering".
> I will read soon.
>> There were some proposals made, but in my view this is the most important one.
>> There are too many "production releases" - at present including versions
>> 7.4, 8.2, and 9.0 .
> 7.4 will be gone soon. Normally when 8.3 goes out, 7.4 will go.
>> Cutting one would refocus devs and users on the remainig two, with obvious
>> benefits to FreeBSD product.
> Three is not normal. Shouldn't it have disappeared with 9.0? Two is normal. 7.4 will be maintained until February next year or so anyway. So, nothing was wasted here.

OK. As someone who has been running FreeBSD for a while (though I am
not an old-timer as I never ran V2), I can tell you that 5 to 6 was a
very smooth upgrade from a fairly broken version (5 had a huge number
of serious issues that could not be fixed without ABI changes) to a
pretty good release that, because it came fairly close to 5.2 (the
first production release of 5), it was still mostly fixes and not new

.0 releases of any large project where version bumps are really
significant are always something to use in production only with great
care. This has been true for years and for almost all operating
systems. It was true with VMS, RSX-11M, IOS (the Cisco one, not the
Apple one), JunOS (Juniper's router OS), Linux distributions and,
until 3.0, Linux kernels.

Recently more and more products have moved from the traditional model
where major version bumps meant major changes, so this is not true
with Firefox, Chrome, Linux kernels, etc., but it is still true for
FreeBSD. And that means that there is a real .0 that will only get
significantly broad use after a release. Staying in BETA for long
intervals leaves important features from getting to a large number of
users, so RE has to draw a line somewhere and say, "We are doing a
release". It is now more or less time based, but it is still when ABIs
and APIs can change which is the key to getting new features out to a
broad audience. It simply as to be done. No one really likes it, but
no one has come up with a better way.
R. Kevin Oberman, Network Engineer
E-mail: kob6558 at

More information about the freebsd-stable mailing list