When Do I Upgrade Major Versions of .NET Core?

10.31.19

The .NET Core Release Cadence-Dance

Microsoft’s .NET Core development platform is great. It’s where all the latest innovation is going on right now. But there is a lot of continuing confusion around the releases and release schedules. The release numbers are important and tell you a lot about what to expect with the release and how it will be supported by Microsoft with security patches and bug fixes. The problem is that the release “code” in the numbering schema is a little different from past Microsoft products, other industry practices and even from the other components of the framework — ASP.NET Core and Entity Framework Core.

On the surface, confusion like this just seems wholly unnecessary — and it is unnecessary. But it’s not the first time that Microsoft has had … shall we just say “naming challenges.” Heck, ten years ago Microsoft had three separate and distinct pieces of Intellectual Property called “ActiveSync.” One was a utility app for mobile devices and the other two were integration API methods. Each had to be licensed separately. So, if you were adding push-updates and notifications to an app you were building, you needed to license ActiveSync and ActiveSync, but not ActiveSync.

It’s enough to give you nightmares in code-land.

Anyway … you can figure out how to keep up with the release updates in .NET Core and, once you get the hang of it, you’ll be able to develop and update your applications with confidence.

Why the .NET Core Release Cadence Matters

It’s completely fine to work with, experiment, and even develop on releases and pre-releases to keep your innovation moving along. It’s not disruptive. But the last thing a developer wants to do is to launch an application into production today on a base framework that will not be supported tomorrow. That is the definition of disruption.

You want your production releases to go live on a stable, fully-supported platform. And if you are in active development, you need to know the risks and prepare for updates and changes on pre-release versions and also on versions that may not have Long-Term Support (LTS). And it doesn’t help that Microsoft changed the definition of LTS in 2018. But it looks like Microsoft has their stuff buttoned up a little better now and they’re sticking to the current definitions and numbering code. So, let’s get to it.

Understanding .NET Core Release Cadence

.NET Core Release Candidates / Preview Releases

As the name implies, Preview / Release Candidates are there to allow developers to start tinkering with the new toys. Not only can we experiment with new, interim versions of functions and features, but we — as a community — can provide valuable insight and input.

These releases have “RCx” appended to their names. For example, the last Preview release of .NET Core was as follows:

.NET Core 3.0 RC1

This indicates the first Preview Release Candidate for the major version release of .NET Core 3.0. There is no limit to the number of Preview releases a version can have, but history suggests just one or two. Importantly, these “RC” versions are not supported for long — usually that means they go End-of-Life (EOL) just a few months after the next official release is launched.

Major .NET Core Releases: Evens & Odds

The current path of production releases for .NET Core has followed a “dot zero” release, then a “dot one” release, followed by a “dot two” release. The “dot one” release is the “odd-numbered” one, and it is also the LTS release. Even-numbered releases — “dot zero” and “dot two” — are generally supported for three months after the subsequent release comes out.

Here are more details.

Major “Dot Zero” .NET Core Releases

Major releases are the big leaps — when software for from 1.x to 2.0, that kind of thing. The releases look like this:

.NET Core 2.0 or .NET Core 2.0.9

They’re called “dot zero” releases because they have a “0” as the second digit. It’s where we get the major new features, functions, and upgrades. And that’s great, but that does not mean that they will be LTS.

Microsoft assumes that once a major “dot zero” release comes out it is going to start getting deployed en-mass. And when that happens, invariably new bugs will be found. And it’s not unusual for certain needed features or components to need additional work. When those have been ironed out, Microsoft wants us all to upgrade as soon as possible to the next major release. Which brings us to ….

Major “Dot One” Releases of .NET Core

Once we get past the “dot zero” releases, we find the “dot one” releases. As you would expect, they’re called “dot one” releases because they have a “1” as the second digit. They look like this:

.NET Core 2.1.13

Importantly: In the new Microsoft support schema for .NET Core, these “dot one” releases are the ones that will have LTS. The current statement from Microsoft is that these releases will have LTS for a minimum of three years — and that’s something you can build on.

Major “Dot Two” (current) Releases of .NET Core

This is where things can get a little confusing. Because once we get past “dot one” releases, updates are considered “maintenance” versions. They look like this:

.NET Core 2.2.7

They can include security updates and bug fixes, but they may also include minor feature enhancements. But … they may not have LTS. If you adopt the interim “dot two or higher” releases, Microsoft wants you to continue your upgrade path with the next “dot one” release. You are likely to find that these releases will end support or go EOL three months after the next release comes out.

Summary — The Best Time to Upgrade Your .NET Core Framework

It is considered a general best practice to always ensure that your software of application is on the latest, fully-patched versions across its entire technology stack. This is true for development frameworks like .NET Core too. But you also need to identify the long-term, stable releases that will be supported with those patches and fixes for the long-haul.

Now you know.