FreeBSD 6.0 and onwards

All,

FreeBSD 5.3 is about to be announced this weekend and will signal the
true kick-off of the 5-STABLE and 6-CURRENT series.  We are very excited
about this, both because 5.3 is a good release, and because 6.0 will
give us a chance to, erm, redeem ourselves and our development process
=-)

5.x was a tremendous undertaking.  SMPng, KSE, UFS2, background fsck,
ULE, ACPI, etc, etc, etc were all incredible tasks.  Given that many of
these things were developed and managed by unpaid volunteers, the fact
that we made it to 5-STABLE at all is quite impressive and says a lot
about the quality and determination of all of our developers and users.
However, 4 years was quite a long time to work on it.  While 4.x
remained a good work-horse, it suffered from not having needed features
and hardware support.  5.x suffered at the same time from having too
much ambition but not enough developers to efficiently carry it through.

By the middle of 2002 is was very apparent that we needed to start
focusing on getting 5.0 released.  Unfortunately, we fell into the trap
of wanting to finish more features in order to feel good about 5.x.  We
kept on ignoring the fact that 5.x already had a lot of good and needed
features, and that the number one goal needed to be to get it stabilized
and turned into 5-STABLE.  Instead we drew up a road map document that
dictated releases based on features rather than on stability and, even
more importantly, timeliness.

There has been quite a bit of discussion about this over the past week
by the developer community.  The proposal that I and Poul-Henning have
set forth is to stop gating releases, both major and minor, or features,
and instead gate them on a schedule that is both reasonable and timely.
New -STABLE branched will be made on a calendar-based time line, and
point releases on those branches will be made at regular intervals.  We
are still debating the exact time line, but it will fall somewhere
between doing a new -STABLE branch every 12-18 months, and doing point
releases every 4-6 months.

While as engineers we all tend to hate timelines, this does have a lot
of positive aspects.  First, it increases the predictability of the
development both for our users and for our developers.  Users can plan
effectively for upgrades and testing/validation knowing that there will
be major and minor releases at fixed times of the year.  Developers can
judge when to start new projects and when to focus on bug-fixing because
there will no longer be the temptation to delay a release by a month in
order to slide 'one more thing' in.  This is not unlike most commercial
OS vendors, and we've received a _LOT_ of feedback that this method of
planning is desperately needed.

Second, it means that development efforts for major features will
continue to shift out of CVS and into Perforce.  This already happens
quite a bit, so it's not as radical of a change as it seems.  CVS HEAD
will remain the 'experimental' development branch, but large items will
not be brought into it until they are functionally complete and
integrated.  HEAD may still get unstable from time to time, but it
hopefully won't turn into the collision of lots of half-done
experimental things like it has in the recent past.  It also means that
if a major feature isn't done in time for a -STABLE branch-point that it
can continue to be developed outside of the CVS tree and be made ready
for the next scheduled branch point.

Third, by having more frequent and scheduled branches and releases, we
avoid the 5.x problem of having too much time to let too many things
get into the tree and dilute developer resources to handle and debug
them.  As I said at the beginning, 5.x has an incredible number of big
things.  6.0 will be more modest, and will 7.0 and on.  We'll know when
to 'stop digging and start climbing', and Robert aptly puts it.

So the current plan is to branch RELENG_6 (aka 6-STABLE) sometime around
May or June 2005.  That will begin a 1-3 month freeze and stabilization
process for the 6.0 release.  After that is released, we will do 6.1,
6.2 and onwards at likely 4 month intervals.  In May/June 2006 we'll
look at doing RELENG_7, or we might wait until Nov/Dec 2006 (12 months
vs 18 months).  The 5.4 release will likely be in Feb/March 2005, with a
5.5 release possibly in June/July, depending on where 6.0 is.  There may
be 5.x releases after 6.0 if 6.0 turns out to not be as stable as needed
(as is often the case with and .0 release).

As far as promising features for releases, this new process means that
we will be getting away from that.  That's not to say that there aren't
many big features that need to be done, but whatever is not done in time
for the 6-STABLE branch will have to wait until after 6.0.

I expect (and hope!) for there to be a lot more discussion on this.
However, it has already been discussed quite a bit at the developer's
summit last Friday and in the days since, so this is really more of an
announcement of the release engineering team and the project's
intentions going forward.  Once 5.3 is formally announced and we've
had a few days to see the results, I'll publish a formal schedule.

Again, thanks to all of the developers and all of the users that have
worked so hard on bringing 5.x forward and keeping 4.x viable.

Thanks,

Scott