I see a lot folks discussing LTS (long term support) and STS (standard term support).
THERE IS NO QUALITY DIFFERENCE
People keep saying that STS is somehow 'less baked' or 'experimental'. That's simply false.
🧵
THERE IS NO QUALITY DIFFERENCE
People keep saying that STS is somehow 'less baked' or 'experimental'. That's simply false.
🧵
Comments
We also don't strategize over which features goes into LTS vs STS. We ship the feature when it's ready. And if it's not, we will often either mark the feature as [Experimental] or put it in a pre-release package.
That's cool, then STS isn't for you. Just pretend .NET ships every two years and *boom* every release is an LTS for you.
It means we need to keep a ton of branches around, a ton of engineering infra to build older versions of the platform, and a ton of effort fixing the same bugs in multiple runtimes.
Yes but it comes with a price tag: less churn. There is basically close to zero innovation in .NET Framework. That makes it much easier to support. It's still costly, but the demand/business need is high enough to justify that.
I remember when the first version of .net core came out ... people where still on .net 4.5 which was not supported.
I think it's an issue of investment in change.
The Tech folks want the Tech. Money people don't care. .NET needs to make the money people care about this support cycle or devs will continue to be caught in the middle.
As you observed, business like stability and support. They won’t change unless there is an incentive.
Tech won’t be that incentive, staying supported is. And we can (and do) offer paid extended support.
It's more the joke that they listen to you. They don't listen to the devs who work on your stacks.
If forcing the upgrade envelope is the only way to get the business to agree to marginal updates. That's what we have.
* generally speaking
These days I update when things are released though. I got a lot better.