FreeBSD 6.0 and onwards

Fri Nov 5 18:09:31 PST 2004

Scott,

Congratulations about the beatiful work!

We got FreeBSD since 1994 (Version 1) and have the confidence in use all new 
releases in production in lot of hosts widespread over large states areas 
here in Brazil. In all of this time we had some insignificant problems in 
version 5.1, only.

So, we know the great work of a great time.

Thank you for take the opportunity to use FreeBSD now and in the future.

Julião
---
Rede Pegasus
http://www.redepegasus.com.br

> 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