Hacker News Reader

Comment by voidmain0001 | Hacker News Reader

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

View on HN

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 (cf. Java at 6 months) while LTS gets a relatively anemic 3 years of support (cf. Java at 8+ years [1]). 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.

[1]: https://www.oracle.com/java/technologies/java-se-support-roa...

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...

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 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.

Reply on news.ycombinator.com