NET Core Releases and Support

Jamshed Damkewala

7/15/2021: this post was revised to update the support period for “Current” releases from 15 months to 18 months, or 6 months after the next release ships.

While we’ve covered .NET Core releases, cadence and support policies in previous blog posts, the information has been distributed across a couple of individual posts. With the .NET 5 release just around the corner, we thought this is a good time to bring all the information together into a single post as a refresher on these topics.

As we’ve covered previous posts, .NET Core releases have a very different model relative to .NET Framework so if you’re coming from .NET Framework application development and familiar with that, or just starting with .NET Core it is important to understand the release cadence, types, and support lifecycle for .NET Core so you can make the right choices for your situation.

Key Highlights

.NET Core ships major releases, minor releases, and servicing updates (patches). From a support perspective, there are 2 support “tracks” for .NET Core releases.

• The first track is “Current” releases – these .NET Core versions are supported for a period of 6 months after the next major or minor release ships.
• The second track is “Long Term Support” or LTS releases – these are supported for a minimum of 3 years, or 1 year after the next LTS release ships (whichever is longer).

.NET Core releases alternate between LTS and Current releases, so it is possible for an “LTS” release that shipped first (for example .NET Core 3.1) to be supported for longer than a “Current” release (for example .NET 5) that shipped later.

Servicing updates ship monthly for the most part and include both security and non-security (reliability, compatibility, and stability) fixes. .NET Core servicing releases are supported from the time they are released until the next servicing update is released. Servicing updates leverage runtime roll forward behavior, that is applications default to running on the latest installed runtime servicing update that is installed, so we take care to ensure a high degree of compatibility in servicing updates. When it comes to getting support for .NET Core, you have a choice between Microsoft assisted support and Community support based on your situation.

The rest of this post covers these areas in more detail:

• .NET Core Release Types – major releases, minor releases, servicing releases, and SDK feature bands
• .NET Core Lifecycle – modern lifecycle, Current releases, and Long Term Support (“LTS”) releases
• Getting support from Microsoft and the Community
• End of Support and Operating System support
• .NET Roadmap

.NET Core Release Types

.NET Core ships major releases, minor releases, and servicing updates (patches).  Information about the release is encoded in the version associated with the release in the form of major.minor.patch.

For example,

• .NET Core 3.0 is a major release of the product.
• .NET Core 3.1 is the first minor release after the .NET Core 3.0 major release.
• .NET Core 3.1.17 has a major version of 3, minor version of 1 and patch update version of 17, that is, it’s the seventeenth patch for .NET Core 3.1.

Major releases

Major releases of .NET Core like .NET Core 2.0, 3.0 or .NET 5.0 generally include new features/functionality, new public surface area, and bug fixes. Due to the nature of the changes, these releases are expected to have breaking changes. All major releases install side by side with all previous major releases.

Minor releases

Minor releases of .NET Core like .NET Core 2.1 and 3.1 also include new features/functionality, public surface area, bug fixes, and may also have breaking changes. The difference between these and major releases is that the magnitude of the changes is generally smaller and therefore an application upgrading from .NET Core 3.0 to 3.1 has a smaller jump to move forward. Minor releases install side by side with all previous minor releases.

Servicing Updates

Servicing updates for .NET Core ship almost every month and these updates carry both security and non-security bug fixes. For example, .NET Core 3.1.8 is the eight update for .NET Core 3.1. When these updates include security fixes, they’re released on “patch Tuesday”, which is always the second Tuesday of the month and predictable. Servicing updates are expected to maintain compatibility and we take steps to ensure this. Starting with .NET Core 3.1, servicing updates are upgrades, that is, the latest servicing update for 3.1 will remove the previous 3.1 update upon successful installation.

Feature Bands (SDK only)

Versioning for the .NET Core SDK works slightly differently from the .NET Core runtime. .NET Core SDK updates sometimes includes new features or new versions of components like MSBuild and NuGet to align with new Visual Studio releases. These new features or components may be incompatible with the versions shipping in previous SDK updates for the same major/minor. Hence feature bands exist as a means of differentiating across such SDK updates.

The .NET Core SDK uses the concept of feature bands. For example, the first .NET Core 3.1 SDK was 3.1.100. This release corresponds to the 3.1.1xx  “feature band”. Feature bands are defined in the hundreds groups in the third section of the version number. For example, 3.1.101 and 3.1.201 are versions in two different feature bands while 3.1.101 and 3.1.199 are in the same feature band. When .NET Core SDK 3.1.101 is installed, .NET Core SDK 3.1.100 will be removed from the machine if it exists. When .NET Core SDK 3.1.200 is installed on the same machine, .NET Core SDK 3.1.101 won’t be removed.

Runtime Roll-forward and Compatibility

Major and minor updates install side by side with previous versions and an application built to target a specific major/minor version continues to use that targeted runtime even if a newer version is installed, that is, the app does not automatically roll forward to use a newer major/minor version of the runtime unless you opt-in for this behavior. An application that was built to target .NET Core 3.0 will not automatically start running on .NET Core 3.1. In general, we recommend rebuilding the app and testing against a newer major or minor runtime version before deploying this to production. For more information, see Runtime Roll Forward.

Servicing updates are treated differently from major and minor releases. An application built to target .NET Core 3.1 targets the 3.1.0 runtime by default and automatically rolls forward to use a newer 3.1.1 runtime when that servicing update is installed unless you opt-out from this roll forward behavior. We default to this behavior because we want security fixes to be used as soon as they’re installed without any other action needed.

.NET Core Lifecycle

Fixed versus Modern lifecycle

The first thing to understand is that .NET Core adopts the modern lifecycle, which is very different from the traditional fixed lifecycle that has been used for .NET Framework releases. Products with fixed lifecycles like the .NET Framework as the name implies provide a fixed period of support, this is typically long, for example, 5 years of mainstream support (including security and non-security hotfixes) and another 5 years of extended support (security fixes only). Products like .NET Core that use a modern lifecycle typically adopt a more service-like support model that is shorter and ship more frequently.

From a support perspective, there are 2 flavors of support “tracks” for .NET Core major (and minor) releases. Each has its unique attributes and may be appropriate in different situations.

Current Releases

These .NET Core versions are supported for a period of 18 months, or 6 months after the next major or minor release ships (whichever is longer). Previously, Current releases like .NET Core 3.0 and 2.2 were supported for a period of 15 months, or 3 months after the next major or minor release shipped.

Example:

• .NET 5.0 shipped in November 2020 and is expected to be followed by .NET 6.0 in November 2021.
• .NET 5.0 support will end in May 2021 (that is, 6 months after 6.0, the successor to 5.0 ships)

Long Term Support (“LTS”) releases

These are supported for a minimum of 3 years, or 1 year after the next LTS release ships (whichever is longer).

Example:

• .NET Core 2.1 was released in May 2018 and was deemed an LTS release in August 2018, so it will be supported for 3 years (i.e. August 2021), or 1 year after the next LTS release, whichever is longer.
• The next LTS after 2.1 was 3.1 and this was released December 2019 (i.e. 1 year from this would be Dec 2020)
• Since August 2021 is later than Dec 2020 .NET Core 2.1 will be supported through August 2021.

It is possible for an older LTS release to be supported for longer than a newer Current release.

For example .NET Core 2.1 is an LTS release and will be supported through August 2021. .NET Core 3.0, which shipped later in September 2019, went out of support in December 2019.

Here’s a picture that shows the support lifecycle for various .NET Core releases. Note that this includes .NET 6.0 and releases in the future, so they’re for demonstrative purposes only. The specific lifecycle dates will be published at the time the releases ship.

If you’re building a service and expect to continue updating it on a regular basis, then a .NET Core “Current” release like .NET 5.0 may be your best option to stay up to date with the latest features .NET Core has to offer.

On the other hand, if you’re building a client application that will be distributed to consumers and this application needs to be supported for a certain period before the consumer can be reasonably expected to upgrade to the next version of this application, then picking an LTS release like .NET Core 3.1 or .NET 6.0 might be the right option.

Servicing releases

.NET servicing releases are supported from the time they are released until the next servicing update is released. The release cadence is typically monthly. This means you need to regularly install servicing releases to ensure that your apps are in a secure and supported state.

For example, if the latest servicing release for .NET Core 3.1 is 3.1.17 and we ship 3.1.18, then 3.1.17 is no longer the latest and the supported servicing level for 3.1 is 3.1.18.

More information about the latest shipped servicing updates for all supported versions of .NET Core can be found on the .NET Core Downloads page.

Getting Support

Microsoft Support

For assisted support with .NET Core technologies, contact a Microsoft Support Professional.

You need to be on a supported servicing level (the latest available servicing update) to be eligible for support. If a system is running 3.1 and the 3.1.17 servicing update has been released, then 3.1.17 needs to be installed as a first step.

Community Support

Community support is another great way to get help and even contribute to projects. See our Community page for details.

.NET Core versions and support

Here’s a snapshot of the end of support date for the various versions of .NET Core. For the most current information you can refer to the .NET Core support policy page.

End of support

End of support refers to the date after which Microsoft no longer provides fixes, updates, or technical assistance for a particular product version. As this date nears, make sure you have moved to using a supported version and have the latest servicing update installed. If you continue to use a version that is out of support, you’ll no longer receive security updates that will be required to protect your applications and data.

.NET Core support and Operating Systems

.NET Core can be run on a range of operating systems. Each of these operating systems has a lifecycle defined by its sponsor organization (for example, Microsoft, Red Hat, or Apple). The .NET Core team applies each of those lifecycle schedules to inform adding and removing support for operating system versions.

When an operating system version goes out of support, we stop testing that version and providing support for that version. Users need to move forward to a supported operating system version to get support.

.NET Roadmap

.NET Core is where new investments in .NET are happening. New applications that want to take advantage of the new features in .NET should consider moving to .NET Core.

Here’s our planned release cadence for .NET Core.

We will ship .NET Core major releases every year, with every alternate release designated as a Long Term Support (“LTS”) release. .NET Core 3.1 is an LTS release and the next one will be .NET 6.0, shipping around November 2021. The one after that will be .NET 8.0 shipping November 2023, and so on. A relevant point worth calling out is that .NET 5.0 is not an LTS release.

.NET Framework

As we’ve covered in previous blog posts, .NET Framework 4.8 was the last major release of the .NET Framework. If you have existing .NET Framework applications that you’re maintaining, there is no need to move these applications to .NET Core. We’ll continue to support and service .NET Framework for bug fixes – reliability and security fixes. .NET 4.8 continues to ship with Windows and will be supported with new releases of Windows. For compatibility reasons, there are no plans to remove .NET Framework 4.8 from Windows.

Summary

If you’re using an out of support .NET Core runtime like 1.x, 2.0, 2.2, or 3.0, we strongly recommend you update your application to a supported version like 5.0, so you can benefit from the security updates and other non-security fixes we ship in our monthly updates.

See our blog post on the .NET 6.0 Preview 6 release for the latest bits and to give this a spin.

Jamshed Damkewala Principal PM Manager, .NET

Follow