The Support Length for .NET LTS and STS versions

As you might know, a new major release of .NET comes out every year. Even .NET releases like .NET 8 and .NET 10 are so-called long term support (LTS) versions, and odd .NET releases like .NET 7 and .NET 9 are short term support (STS) versions.

You might ask yourself when you should switch to a new version. Let’s clarify this.

What about the quality?

That’s a common misunderstanding. Quite often I hear developers saying they are only using the LTS versions and not the experimental STS versions. That’s actually not correct. In terms of quality, they are all the same. The only difference is the length of support. Even when looking at the official docs from Microsoft for the support policy, you can find this there:

The quality of all releases is the same. The only difference is the length of support. LTS releases get free support and patches for three years. STS releases get free support and patches for two years.

https://dotnet.microsoft.com/platform/support/policy/dotnet-core

The common end date for LTS and STS

Originally, STS had support for only 1.5 years. LTS had always support for 3 years. This 1.5 years support length for STS releases led to a problem. Let’s say you were on .NET 6, which was an LTS release with 3 years of support. One year after the .NET 6 release, the newer .NET 7 came out, which was an STS release with 1.5 years of support.

That meant that at the time .NET 7 came out, you had this situation:

  • .NET 6 has 2 remaining years of support
  • .NET 7 has 1.5 remaining years of support

That meant by switching from .NET 6 to the new .NET 7 version, you decrease the support time by half a year. So, understandably, many developers just stayed on the LTS releases like .NET 6 and never updated to an STS release like .NET 7.

Microsoft noticed this issue. Since .NET 9, the STS versions have not 1.5 years of support, but instead 2 years of support. You can find the original announcement here: https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/

What does the increase of STS support length actually mean?

Let’s take .NET 8 and .NET 9 as an example. When .NET 9 came out, the situation looked like this:

  • .NET 8 has 2 remaining years of support
  • .NET 9 has 2 remaining years of support

This means that the support for the LTS and STS version ends at the exactly same date, which is according to https://dotnet.microsoft.com/platform/support/policy/dotnet-core for .NET 8 and .NET 9 November 10, 2026.

When .NET 11 comes out, the situation is similar with .NET 10:

  • .NET 10 has 2 remaining years of support
  • .NET 11 has 2 remaining years of support

That means that you can switch your projects to .NET 11 if you want, and you will get exactly the same remaining support length as .NET 10, and in addition the latest .NET and C# features for your projects.

This also means that with the release of a major version, the previous LTS and STS versions have 1 year of remaining support. When .NET 12 comes out, it will look like this:

  • .NET 10 has 1 remaining year of support
  • .NET 11 has 1 remaining year of support
  • .NET 12 has 3 remaining years of support

So, from a length-of-support perspective, it’s always worth to switch to a new major version of .NET.

What does switching to a new .NET version mean?

Usually, switching to a new .NET version means that you update the version in all the C# project files (.csproj) of your solution. Then you compile and run your tests. You check in addition the breaking changes on https://learn.microsoft.com/dotnet/core/compatibility/breaking-changes of the version you’re switching to. And of course, check also the impact on the NuGet packages that you reference.

But in my experience, bumping the version of .NET was always a very straight-forward task. This is one of the reasons why I love .NET, things are evolving and growing, but not radically changing with new versions, which made the switch to a new version in the past a joyride. And I strongly believe this stays the same for future versions.

– Thomas

Share this post

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.