Nothing new to comment on here. MS has been open about its long term and short term releases based on even and odd numbers. Unsurprisingly, there's a web page that explains it https://dotnet.microsoft.com/en-us/platform/support/policy

This whole thread is a bit of a tangent, but I'm not sure the STS/LTS distinction makes much sense for the end user. STS gets a relatively generous 2 years of support while LTS gets a relatively anemic 3 years of support. Plus, with yearly releases, every LTS expires at the exact same time as its successor STS. Are STS releases generally less stable or more experimental than LTS releases? Otherwise, this feels like a valueless distinction.

Yes, STS releases tend to be more experimental and the LTS shores up the gaps.

That may have been true in the past, but that is not the stated policy: "The quality of all releases is the same. The only difference is the length of support."

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

Well, yes, that's the official narrative, but if you seen .net 5, .net 7, and .net 9, and .net 11 and compare them to the LTS that came after them, it's easy to see that pattern.

.net 5 brought records,and then .net 6 brought record structs.

.net 9 previewed the field keyword, and .net 10 released it.

.net 5 brought primary constructors for records, then .net 8 expanded that to classes.

There's a few opposite examples too, but it's a trend I felt over the past decade.

My only wish is they just jumped C# and .NET versions to the year number, since they are incrementing annually anyway, and aren't do semver anymore.

Supporting anything for 8 years is a huge commitment. That means 8 concurrent versions needing at least some work all the time.

I think Microsoft regretted those long (10 years) support guarantees they had for .net framework. In the end, it probably slows you down in terms of innovating

Given .NET's annual release cadence, 7-8 years of LTS would mean 5 concurrent versions: 1 STS release and 4 LTS releases. This is still a lot of old versions to keep updating, of course.

Anyway, the critique was less about the exact length of LTS, and more about the lack of significant difference between LTS and STS, i.e. why should I choose LTS in the first place. With STS, you have 2 years of support, and 1 year to upgrade. With LTS, you have 3 years of support, and 1 year to upgrade.

>They burried the lede on this one.

Not really for any groups that commonly use .Net. Even numbers are LTS and odd numbers are not, or at least it's been this way for a while.

>I have clients who refuse to budge from 2.1

Give me their names, sounds like it would be easy to penetrate them again and again and again with AI.

Plus the even/odd LTS/short-term cycle matches Node.js and some others as a release pattern.

[delayed]

If you mean ASP.NET Core 2.1 or ASP.NET Core 2.3, then they are actually .NET Framework despite the name, and are not the same lineage as .NET 10 and .NET 11.

It's still in support, and led to one of the most confusing release announcements in history: https://devblogs.microsoft.com/dotnet/servicing-release-advi...

ASP.NET Core 2.3 does go end of life in April however: https://devblogs.microsoft.com/dotnet/aspnet-core-2-3-end-of...

It's not that complicated. ASP.net Core 2.2 and earlier was targeted at .NET Standard, so could run in any CLR (CoreCLR or Framework or even Mono, though I don't know how supported mono was). Asp.Net Core is actually just a csharp library like everything else.

ASP.NET Core 2.2 could not run on .NET Framework, which is why 2.3 was a re-release of 2.1.