FreeBSD release process comparison

[paean]

Hi All,
I recently watched Theo de Raadt's message from AsiaBSDCon 2009 regarding OpenBSD's release process. It was interesting, particularly because of the regular comparisons to FreeBSD's release process.

Without inciting any "x is definitely better than y" discussions, I'd appreciate hearing why the FreeBSD user group has decided on its release method vs the OpenBSD method (or others). Having read the Release Engineering document, I understand the how, just not necessarily the why.

If nothing else, one hint can be found on the Lesson's Learned page:

Our user community has made it very clear that the security and stability of a FreeBSD release should not be sacrificed for any self-imposed deadlines or target release dates.​

 

[paean]

So those who have helped determine the FreeBSD release mechanisms either don't read the forums or aren't interested in explaining themselves?

 

[DutchDaemon]

These forums are specifically a user and 'self help' community, nothing more; there are some developers and contributors here, but the FreeBSD mailing lists are where the development and release engineering and related discussions take place. The RE people are busy beyond imagination (day jobs and FreeBSD development and release engineering, with 7.3 just out) and already participate in the mailing lists, which are also quite busy. I did shoot off a PM to RE staff when your topic came up, but I can imagine there's just no time and room to cover yet another base.

 

[gilinko]

As this forum is very young most of those topics are either in the mailing list archives or best to be answered in the mailing lists themselves. But there are some articles about the structure A project model for the FreeBSD Project and FreeBSD Release Engineering.

 

[fronclynne]

Being nothing more than a user, I'll try to chime in on why I think that the FreeBSD model has some advantages.

The reservation of major version number bumps for fairly important changes in the operating system, and maintaining at least a semblance of API & toolset stability throughout the life of a major version is nice. I'm afraid that a lot of designers and coders (and even worse, the home tuners) forget that in the real world we like to use our computers to do stuff. Better performance is nice, spiffy new blinkengadgets are fun, I'm sure, but I do still so love to actually be able to see the e-mail that I get. And when I upgrade to the next major version I do expect that Stuff Will Changeâ„¢. Hopefully the extra learning will pay me back in added function, but being able to use an obsolete version (like 6.x) that is still supported is also nice if that's what works.