I don’t mean finish FreeBSD forever and go home - I mean finish a release.
Set some goals, release software that achieves those goals, and keep fixing bugs that are found.
If you have some new goals (support new hardware, add new feature), work on those in the next release. But don’t abandon the old release, because it still works to achieve the original goals.
What I’m suggesting to avoid is the situation where a bug is found and the user is told “it’s fixed in the next release”. If the bug compromises the goals of a release, it should be fixed in that release!
Sure you’d have to support old releases for much longer, but that’s not the hard part.
The hard part is deciding what the goals are in a precise and coherent way (for this purpose, goals should be the set of promises made to the user, which when broken give rise to a bug). I don’t think any large software project has good discipline here. I don’t think it’s been done before for an OS. But I’m talking about differentiation here.
Thanks for the clarification. In practice what that means to me is you need more people backporting fixes to the old branch. My experience: it's boring, thankless work and it doesn't pay unless there is some serious investment behind it, think heavily-audited systems deployed in government offices that have to stay the same for decades.
Set some goals, release software that achieves those goals, and keep fixing bugs that are found.
If you have some new goals (support new hardware, add new feature), work on those in the next release. But don’t abandon the old release, because it still works to achieve the original goals.
What I’m suggesting to avoid is the situation where a bug is found and the user is told “it’s fixed in the next release”. If the bug compromises the goals of a release, it should be fixed in that release!
Sure you’d have to support old releases for much longer, but that’s not the hard part.
The hard part is deciding what the goals are in a precise and coherent way (for this purpose, goals should be the set of promises made to the user, which when broken give rise to a bug). I don’t think any large software project has good discipline here. I don’t think it’s been done before for an OS. But I’m talking about differentiation here.