[throwawaysysd]

>Wouldn’t it be great for FreeBSD to be the first OS to have a release that was actually, truly finished?

I don't mean this in a rude or dismissive way but these comments make me want to pull my hair out. Deciding your software has a fixed scope and is finished doesn't stop the wheels of progress from turning. Worst case, the rest of the world will decide the scope you chose was crap, for reasons beyond your control, and then your project is dead. I get that it is an engineer's fantasy to build a theoretically "perfect" system but such a thing can't exist in practice. I think you'd have a better chance of proving P=NP or something.

[ThinkBeat]

I disagree.

There is no good reason why one should strive for a piece of software to be eternal.

It would be much better to say, well this is what we wanted to accomplish. The program does a good job now.

Later it might be time to build something else.

You build a nice warm and cozy cabin in the woods, and you like it. Keeps you warm and dry. Success.

Now 15 years later, the area is no longer in the woods, rather it is now zoned within a city to have duplexes.

You can then think that you built such a great building that now you need to remodel it into a duplex, and then a quadplex and then a skyscraper.

I think saying "my cabin was very good, now I have to let go of it and and build something else" is a much better approach.

It is nearly delusional to think that you will write a program that will be good enough to be prepared for what the future brings.

We need ot let things die and build again.

[jl6]

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.

[throwawaysysd]

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.

[torstenvl]

Off the top of your head, what is there in Office 2021 that you genuinely want to use and isn't in Office 2019?

[shakna]

Python scripting support?

There is a good reason for new features. But it might be nice if those features came as part of an official set of extensions around a stable core, to get the best of both worlds.

[oblio]

If they're just extensions they increase the support matrix greatly. Trade offs.

[shakna]

Not necessarily. They're all features that currently exist in the core product, making that product larger and more error prone. Thus, the support story is either the same, or smaller if one of those features isn't activated.

Having them run as extensions doesn't mean that there's a public extension API, you can keep that interface all to yourself. It means that from the developer's perspective, there's a core offering that the most senior members can handle, but the smaller features are both bundled, and can be more easily passed to other teams.

It's the same idea behind using libraries, instead of shoving all the code into one place. But it forces you to have a single structured interface to extend the product, instead of touching every other file when you want to add something.