We are increasing the length of support offered for .NET Standard Term Support (STS) releases from 18 months to 24 months. This change is effective starting with .NET 9, which means .NET 9 will now reach end of support on November 10, 2026. There is no change for Long Term Support (LTS) releases, which will continue to be supported for three years.
Note that all components in the .NET family do not follow the same support lifecycle as .NET, some components ship out-of-band with .NET and have their own independent support lifecycle, today’s announcement does not change that. More information including the end of support dates for .NET and these out-of-band components can be found on the .NET support lifecycle policy site.
How .NET support worked previously
.NET ships a new major release every year in November for a consistent, repeatable roadmap. Even-numbered releases are Long Term Support (LTS) releases and get support, including updates, for three years, or 12 months after the next successor release ships. For example, since .NET 10 will ship on November 11, 2025, .NET 8 is scheduled to reach end of support 12 months later, on November 10, 2026. This has not changed.
| Version | Original release date | Latest patch version | Patch release date | Release type | Support phase | End of support |
|---|---|---|---|---|---|---|
| .NET 8 | November 14, 2023 | 8.0.20 | September 9, 2025 | LTS | Active | November 10, 2026 |
Odd-numbered releases are STS releases and were supported, including updates, for 18 months, 6 months after the next successor release shipped. For example, since .NET 10 will ship on November 11, 2025, .NET 9 was scheduled to reach end of support on May 12, 2026.
| Version | Original release date | Latest patch version | Patch release date | Release type | Support phase | End of support |
|---|---|---|---|---|---|---|
| .NET 9 | November 12, 2024 | 9.0.9 | September 9, 2025 | STS | Active | May 12, 2026 |
STS releases will be supported for 24 months, 12 months from when the successor release ships. This means that .NET 8 and .NET 9 will reach end of support on the same day – November 10, 2026.
Why make this change?
We know some customers choose to stay on LTS versions due to the longer support timeframe available for these releases. Some enterprises even have internal policies requiring development teams only use LTS versions.
At the same time, .NET is evolving fast. We ship more features as out-of-band (OOB) releases on a regular basis where we previously might have waited for the next annual release train. .NET Aspire, Microsoft.Extensions.AI, and the C# Dev Kit are examples of OOB releases that regularly ship new features.
From the previous example you can see that .NET 9 which shipped a year after .NET 8 will reach end of support 6 months before .NET 8 reaches end of support. This can be a problem in some cases.
Sometimes, an OOB release includes a dependency on an updated version of a package that ships in the annual release train. If you have made the choice to stay on LTS releases exclusively and then install one of these OOB releases that will move the LTS package version to a newer STS version this can cause problems. Since the package now belongs to an STS release, you have inadvertently moved part of the runtime from LTS to STS and will receive support and updates per the STS lifecycle for that package. As in the .NET 9 example, this support could end sooner as compared to if you had stayed on .NET 8.
Alternatively, you may discover this problem and choose not to use the OOB release to avoid this problem, which means you’ll miss out on the functionality in the OOB. The STS package version dependency is now an adoption blocker for the OOB.
To solve this problem, we’re making a change to the STS support lifecycle – STS releases will be supported for 24 months, 12 months from when the successor release ships, which means that .NET 8 and .NET 9 will reach end of support on the same day – November 10, 2026.
| Version | Original Release Date | Latest Patch Version | Patch Release Date | Release Type | Support Phase | End of Support |
|---|---|---|---|---|---|---|
| .NET 9 | November 12, 2024 | 9.0.9 | September 9, 2025 | STS | Active | November 10, 2026 |
Now, if an OOB release pulls in a newer package version from LTS (.NET 8) to STS (.NET 9), you’ll still be supported through the same date you’d have had if you stayed on the LTS version. Even if you weren’t using any OOB releases, we expect having a longer support window for STS releases will make it easier to consider STS releases for your needs in the future.
Closing
We think you will like this change. That said, if you’re planning on upgrading from .NET 9 to .NET 10 soon, you should continue with your upgrade plans since .NET 10 brings a lot of new capabilities and better performance.
Apple releases a new iPhone every year with a standard support policy up to an iOS version. Most people don't upgrade their phones if they are still happy with them. Some people are forced to buy a new phone due to their phones being broken, or it's wiser to upgrade instead of fixing the stale ones, or they can just take the risk of using the stale ones as long as they can save costs.
I really like this change to STS. However, I believe if we want to incentivize other organizations to upgrade, we should just keep moving on with...
Yup, in our DevOps environment we get a lot of alerts on software running unsupported .NET versions. By the time the software vendor updates it, it seems like that LTS version is about to go out of support as well. This is just madness for all involved.
While this sounds good, it really changes nothing. Companies that require LTS aren't going to suddenly start using STS just because the dates line up. So making this change isn't going to bring people onboard to get adoption rates up. I suspect that is the real rationale here. The # of people using the STS releases isn't high compared to the LTS releases.
I get it, maintaining libraries across multiple versions is hard. This is how the rest of the world does it though. If it is hard to do then why not focus on the solving the problem...
That’s good. We currently adhere to an LTS-only policy as it provides stability and predictably. The longer STS timeframe would enable us consider using odd numbered releases. When looking at new features that are available in later releases, it does feel sometimes that remaining on LTS means we’re missing out on what .Net has to offer.
That's... nice, but what we really want is an LTS release that deserves the name. What .NET currently has is a short-term-support branch (currently called LTS) and a very-short-term-support branch (currently called STS). :-)
Let me explain with an example: You develop a .NET based line-of-business software solution and release it in May 2025. No matter which .NET version you choose (8 or 9), both of them will run out of support 1.5 years later. Sure, I can tell a potential customer that I can only guarantee that my software will run in a supported way for 1.5 years, and, after...
Great news! This removes the shorter time-frame for moving from STS to LTS and any support disadvantages with STS over LTS. Great for new projects, and makes it easier to motivate moving from LTS to current STS versions when they release to get the benefits from them, even thou of course it's still some extra work in that case. I wonder about go-live support for .NET 10 RC1 thou, since it ends before .NET 10 LTS is released and no information about a .NET 10 RC2. Is an RC2 planned? Otherwise it's pointless to even offer production support for .NET...
Just simply get rid of STS and LTS altogether.
Just release a new version with support for 3/4 years and be done with it.
Why always complicate things.
Thanks for the reply.
As the frameworks matured, significant new features are not as mindblowing as they were before, so waiting half a year more doesn't sound that bad - and remember, previews would still be there for those that need the cutting edge. The problem with the current model is that people view STS as a sort-of preview/beta anyways, even though that's 100% wrong.
Your second point I don't see. With the change described in the post, library creators will have to support 2 releases simultaneously anyways (9-10, 10-11, 11-12 and so on). My alternative proposes the same. Or even, supporting...
Library maintainers will be burdened, because they would have to support each .NET version for longer, which will make it harder for them to use new APIs (without adding polyfills). In November 2026, the earliest supported version of .NET will switch from .NET 8 to .NET 10, while if all .NET versions were supported for three years, it would switch to .NET 9. I'm OK with extending STS support to two years, because the timing of changes to the minimum supported version remains the same.
And trust me, there is mind-blowing stuff for me on every .NET release, and more time...
It's worth pointing out that even in a greenfield project, and even when there isn't a strict policy to use LTS releases only, it sometimes made sense to choose the previous LTS version simply because it had more supported time to switch to the next version when it becomes available (12 months instead of 6 isn't something to frown at).
This change makes it hard to defend not starting a project on the latest version, be it an STS or an LTS version.
BUT. This whole requires education on the consumer side. And they mostly come in with baked in assumptions, like...
This will lead to a worse situation for everyone. A longer release cycle will mean that people will get new features more slowly, and a 3-year support lifecycle for all versions will increase the burden for library maintainers to support old versions.