Long Term Support… or not?

As stated in the intro, .NET comes with its own product lifecycle which was introduced along with .NET core. It’s nicely documented here: https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core and in basis comes down to one release each year, as we can see in this list:

• 2016: .NET Core 1.0
• 2017: .NET Core 2.0
• 2018: .NET Core 2.1 (LTS)
• 2019: .NET Core 3.1 (LTS)
• 2020: .NET 5.0
• 2021: .NET 6.0 (LTS)
• 2022: .NET 7.0

This year, 2023, .NET 8.0 will be added to this list which is another LTS version. LTS stands for “Long Time Support” which means exactly that: Microsoft will provide support for that version for a long(er) time. To be precise: .NET 6.0 was released Nov 9, 2021 and will be supported until Nov 12, 2024.

Long term

Note that the use of “long term” in this case, is actually: three years. For a lot of our customers, especially the Enterprise-sized ones, three years in itself isn’t necessarily “long term”. If we take a look at the lifecycle of the full .NET framework as listed here: https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework, we can see that .NET framework 4.7 and up don’t even have an listed end date for support at the time of writing. At quite a few of our customers, the main framework in use is still .NET 4.8; even though that’s now almost 4 years old and counting. So “long” term is also a relative term.

Next to the above mentioned long term support, there’s also standard term support (STS). For .NET 7.0, which was released 8 Nov, 2022 the standard term support is valid until May 14th, 2024. That’s roughly 1.5 years. In fact, an STS release is supported 6 months after release of the LTS version.

Support

Next definition we should consider is “support”, what does that mean? There’s some information on that topic we can find at https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core. It boils down to the product being actively patched for issues, which can be functional, related to security or performance. They will also add support for new OS versions or hardware platforms. Microsoft will patch the frameworks and update them on Windows machines in their Patch Tuesday releases. Note: this only applies when you’re not shipping .NET as part of your executable, which implies you’ll need to distribute the patches yourself!

The following is also interesting:

LTS releases will receive only critical and compatible fixes throughout their lifecycle. STS releases will receive these same fixes and will also be updated with compatible innovations and features.

So where an LTS release is fixed, STS releases might get a few new goodies along the way.

Considerations

In order to make the right decision on which frameworks are allowed to be used, we should take into account some considerations:

1. Support, as mentioned above. 3 years vs 1.5 years with the added sidenote that after 1 year there will always be a newer framework version available.
2. Features. Waiting for the next LTS release means you cannot benefit from the new features in the meantime. Also take into account developer satisfaction, it can be very frustrating for your developers to visit conferences or watch YouTube clips featuring the shiny new stuff whilst not being allowed to use it.
3. Cost of upgrading. Upgrading your .NET version yearly to keep up with the active framework version might take a little bit of effort. On the other side; going from LTS to LTS release is a bigger step. And changes are high that your software will require patching of other packages (NuGet) as well.
4. Risk. Some sort of risk management is in play here. What’s the risk of having an unsupported version of .NET running inside of your landscape? How good are your monitoring processes for tracking it down and how well is your own lifecycle management for ensuring it, when found, gets updated? Some might also consider the risk of running a brand new version, but we’d like to note that every new version is very well tested and first goes through a preview phase before it’s released.

Microsofts take

So what’s Microsofts own advice on this? We’ve searched for it, but other than some pretty obvious statements which basically repeat the above in different wording, there’s no real advice to be found. Microsoft simply states: pick what suits you, which leads to a lot of customers going for the LTS route.

Our take

Being developers who are looking to create value for our business, we’re opinionated on this topic. Most of us like using the latest and greatest simply because those new features are there for a reason: they make our jobs easier or the software more reliable, faster, easier to maintain, etc.

At the same time, support is something we cannot and should not ignore. Having a policy on this topic is important. In our opinion, choosing between STS or LTS releases should be linked to the development state of the software where it’s being used:

• Are you actively developing your software? In that case there’s nothing wrong using the standard term supported release as long as your team can commit to updating it to the next long term release within the 6 month support window.
• Is the software itself in a “support mode”, not actively being worked on? Long term support is the way to go, along with the sidenote that active patching on any dependency should be in place. In an upcoming post we’ll discuss how to automate this maintenance.

This policy would combine using the latest and greatest with having proper support for software which is not being actively worked on. But any development team or department should realise that the days in which software could be left alone for months or years, are long gone and maybe should have never existed in the first place.