more FreeBSD releases

[Oliver_H]

http://lists.freebsd.org/pipermail/f...ne/042840.html

As some of you may know the FreeBSD Project has been attempting to shift over from "Feature based releases" to "Time based releases" as far as trying to schedule them goes. Lets just say that's still a work in progress (as in doing that with FreeBSD 7.0 didn't work out so well).

Propably nice from a desktop users point of view, but to some degree I think it doesn't fit for servers so well. But your mileage may vary ;-)

[J65nko]

I don't regard OpenBSD as a desktop OS but it has done "Timed based releases" for years. One release at 1st of Nov, the other at 1st of May.

[ninjatux]

Isn't this similar to a rolling release system in that you get what the developers think is stable out of what has been implemented up to that point? If someone really needs that, then why not just run CURRENT?

[scottro]

It's not dissimilar. How's that for sticking the old neck out?

With FreeBSD at least, at any given moment in time, especially if you are running something besides RELEASE (e.g., STABLE) you are on a rolling release system.

[JMJ_coder]

Hello,

I, for one, don't like a time-based release system. It seems so "packaged", as if it is released just so they can say they have a new version - even if the only difference is the titlebars are one shade darker.

The features-based system is much better for the consumer. If a hundred new great and improved features are developed in three months, great - version 3.0 in January and 3.1 in April. If it takes you two years to revamp the TCP/IP stack to make it 1000x more secure, great - a new release two years later.

A features-based system also makes it much easier to stick to a proper UNIX version numbering system (i.e., Major.minor.revision). In a time-based system, the numbering becomes almost arbitrary.

There is certainly a divide in FOSS today over which way to go. Some groups want the bleeding edge and have constant versions coming out (i.e., Fedora). Some will only put out a new release when necessary (i.e., Slackware).

But, as I said, I prefer the features-based system. Let's not go after new just to be new.

[TerryP]

I agree wit JMJ about the feature based system -- one thing I've actually liked about FreeBSD releases is the "Oh, whats cookin' new" moment ;-)

Dunno about everyone else but I tend to remember things that change in regard to releases, such as when csup became part of the system and installing cvsup (or csup) began the move into historical interest.


OpenBSDs near clockwork releases on the other hand have never let me down in the short time that I've used OpenBSD (since a lit' bit before 4.0s release). Every time I've seen a release made, I've always been proud at the notes and instructions that come along with it -- that's what I call doing it the right way. And never have I wound up screwed over and fumbling through commit messages to figure out what the without warning broke !


How the heck they do it in time for a six months schedule, I'll never figure out >_>

[jggimi]

Originally Posted by TerryP

...How the heck they do it in time for a six months schedule, I'll never figure out >_>

4 months of development, 2 months of robust testing.

[phoenix]

Originally Posted by ninjatux

Isn't this similar to a rolling release system in that you get what the developers think is stable out of what has been implemented up to that point? If someone really needs that, then why not just run CURRENT?

Because a RELEASE is pretty much guaranteed to work, and everyone can be sure tat when they install X.Y-RELEASE, they all get the same stuff. Two people updating to -CURRENT at 8:05pm on Monday are not guaranteed to get the same bits. Those two alone are more than enough reason to only run -CURRENT if you know what you are doing, know what you are getting into, know how to debug things if they break, and really, really, really need a feature that is only available in -CURRENT.

For the rest of us, having a known-good, consistent, working base is nice.

[phoenix]

Both systems (feature-based "ship when it's ready and not before" and time-based "ship whatever is working on this date") have their pros and their cons.

The biggest con for a feature-based release schedules is who gets to decide which features are the must-haves, and how long are people willing to wait to get them in shippable shape?

The biggest con with time-based release shedules is the lenght of time you select (6 months, 9 months, 12 months?), how much effective work can be done in that time (ie how much is devoted to testing, QA, and RE), and what to do when features aren't complete at the cut-off (how many times can one feature be bumped before people get mad?).

For major, revolutionary changes, feature-based schedules work better. For minor, incremental changes, time-based schedules work better. Merging the two methods (which is what I believe they are aiming for) is a good mix: a major new release every 18-ish month, a minor release every 6 months.

That way, development happens in -CURRENT, with -STABLE branches made every 18-ish months, with all the big, major changes happening there. When the new features are ready for release, they are included into the next major release (or MFC'd to previous releases if possible). And new releases are made from -STABLE (X.1, X.2, X.3) every 6-ish months with whatever new developments have occurred since the last minor release.

[ocicat]

Originally Posted by phoenix

...what to do when features aren't complete at the cut-off (how many times can one feature be bumped before people get mad?).

Customers can be mad in either model, so it comes down to the truthful assessment of where development is internally & project management -- managing external (customer) expectations, monitoring, assisting, & pushing the development effort, & the general management of expectations made by all.

The model used by OpenBSD has been quite successful, & both FreeBSD & NetBSD are making efforts to move in the same direction. Timed releases can be painful, but they also bring a degree of reality into the process, & help refine the release process itself. Timed releases also keeps stability firmly in the picture as amorphous development efforts aren't allowed to exist for extended periods of time.

[Oliver_H]

Originally Posted by J65nko

I don't regard OpenBSD as a desktop OS but it has done "Timed based releases" for years. One release at 1st of Nov, the other at 1st of May.

That's true, but then they don't care about many things and that's the big difference to FreeBSD.

[BSDfan666]

I use OpenBSD on my desktops, seems like a "Desktop OS" to me..