In a followup post to my original January 2012 rant, I suggested the following[1][2]:
- A major release every 5 years
- A minor release every 4-6 months
- total focus on the major release for essentially that entire 5 year period
Obviously there are more details than that, but the point is, it's not the five year number that matters - it's the number of branches floating around simultaneously that is the real problem.
"Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle."
So ... in looking at this new announcement, it seems like they are addressing some points that I have brought up in the past, but in reality I think they are addressing completely different issues, especially with regard to applying security errata, etc.
The problem I see is the (short) two year embargo on a new release, which means that over the five year lifecycle of a release, potentially two other releases come out, which is basically what we have now. Bug fixes and driver updates get written and applied to the sexy new tree[3], and the "supported" release that's all of two years old gets none of it.
That's great that it's around for five years, and I appreciate the clarity there - but there is more to support than the ports tree and security errata. True support is the developer community working in and with a release for years, and that hasn't happened since 4.x.
The problem I see is the (short) two year embargo on a new release
If support for a new device can't be merged into older releases because it relies on ABI/API breaking changes, do you want to be told that you won't be able to use your shiny new hardware in a FreeBSD release for the next five years?
Two years is a compromise between "don't try to support too much at once" and "make sure that people don't have to wait too long to access new features".
"If support for a new device can't be merged into older releases because it relies on ABI/API breaking changes, do you want to be told that you won't be able to use your shiny new hardware in a FreeBSD release for the next five years?"
Yes.
As a business user of FreeBSD, with shareholders and a board of directors, etc., we make very conservative hardware decisions and we try to amortize our investments over as long a period as is practically possible.
I've never thought this argument was that convincing, especially given the propensity to see FreeBSD as a server OS. The fancy things are never ready in the first release they go into anyway, so it's not like we gain much, from a practical standpoint.
Then maintain your own branch like other business users who want to have a stable branch for extended periods of time. And back port the drivers internally if you need them back ported. Literally nobody is preventing you from doing so. There are, however, people that donate extremely large sums of money to the FreeBSD foundation who do support their current release cycles.
First, my suggestions above were made originally in January of 2012, at which time I committed $50,000 to the FreeBSD project in return for adopting something like those suggestions.
So your "put your money where your mouth is" trump card was not quite what you thought it was. Thanks for playing.
Second, I reject the notion that nobody but core developers and big business has useful viewpoints as to the direction of the FreeBSD project (or any project, for that matter). You think you know what kind of resources you are talking about, above, when you speak of developing and maintaining a custom branch and backporting drivers, etc. Take that number and triple it and that's a starting point for the true amount of cost something like that would take in a real organization with real HR and QA and benefits and shareholders and a functioning board, etc. ...
... and that's out of the realm of even mid sized shops.
Spacing major releases out by five years doesn't guarantee that the bug fixes and driver updates you want will make it into the stable release. It's completely plausible that volunteers will instead develop on HEAD and commit their work there, and the changes won't be merged to the stable branch at all.
I started as a FreeBSD developer in the 4.x era. It was somewhat of an anomaly. The SMP work that went into (and delayed) 5-CURRENT was absolutely necessary, but it introduced significant instability and ongoing breakage. That was a strong disincentive to using it as a day-to-day development platform. I needed a stable development and build machine, so it ran 4.x.
Since then as a project we've done increasingly well at keeping -CURRENT in a working state. It is completely feasible for a volunteer developer to run only -CURRENT.
- A major release every 5 years
- A minor release every 4-6 months
- total focus on the major release for essentially that entire 5 year period
Obviously there are more details than that, but the point is, it's not the five year number that matters - it's the number of branches floating around simultaneously that is the real problem.
"Instead of having a legacy branch and two production branches, you would have legacy (8) production (9) and ... nothing. Or if you need to have it out there, 10 is the development branch. Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at the end of the cycle."
So ... in looking at this new announcement, it seems like they are addressing some points that I have brought up in the past, but in reality I think they are addressing completely different issues, especially with regard to applying security errata, etc.
The problem I see is the (short) two year embargo on a new release, which means that over the five year lifecycle of a release, potentially two other releases come out, which is basically what we have now. Bug fixes and driver updates get written and applied to the sexy new tree[3], and the "supported" release that's all of two years old gets none of it.
That's great that it's around for five years, and I appreciate the clarity there - but there is more to support than the ports tree and security errata. True support is the developer community working in and with a release for years, and that hasn't happened since 4.x.
[1] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...
[2] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-Jan...
[3] bank on it.