.NET Core 1.0 and 1.1 will reach End of Life on June 27, 2019
.NET Core 1.0 was released on June 27, 2016 and .NET Core 1.1 was released on November 16, 2016. As an LTS release, .NET Core 1.0 is supported for three years. .NET Core 1.1 fits into the same support timeframe as .NET Core 1.0. .NET Core 1.0 and 1.1 will reach end of life and go out of support on June 27, 2019, three years after the initial .NET Core 1.0 release.
After June 27, 2019, .NET Core patch updates will no longer include updated packages or container images for .NET Core 1.0 and 1.1. You should plan your upgrade from .NET Core 1.x to .NET Core 2.1 or 2.2 now.
Upgrade to .NET Core 2.1
The supported upgrade path for .NET Core 1.x applications is via .NET Core 2.1 or 2.2. Instructions for upgrading can be found in the following documents:
Note: The migration documents are written for .NET Core 2.0 to 2.1 migration, but equally apply to .NET Core 1.x to 2.1 migration.
.NET Core 2.1 is a long-term support (LTS) release. We recommend that you make .NET Core 2.1 your new standard for .NET Core development, particularly for apps that are not updated often.
.NET Core 2.0 has already reached end-of-life, as of October 1, 2018. It is important to migrate applications to at least .NET Core 2.1.
Microsoft Support Policy
Microsoft has a published support policy for .NET Core. It includes policies for two release types: LTS and Current.
.NET Core 1.0, 1.1 and 2.1 are LTS releases. .NET Core 2.2 is a Current releases.
- LTS releases are designed for long-term support. They included features and components that have been stabilized, requiring few updates over a longer support release lifetime. These releases are a good choice for hosting applications that you do not intend to update.
- Current releases include new features that may undergo future change based on feedback. These releases are a good choice for applications in active development, giving you access to the latest features and improvements. You need to upgrade to later .NET Core releases more often to stay in support.
Both types of releases receive critical fixes throughout their lifecycle, for security, reliability, or to add support for new operating system versions. You must stay up to date with the latest patches to qualify for support.
The .NET Core Supported OS Lifecycle Policy defines which Windows, macOS and Linux versions are supported for each .NET Core release.
So if we are using Web Deploy to an IIS server the process of staying security patched is to manually download an install the latest 2.1 release on each server. An in the code to specify PackageReference Version=”2.1″ Until 2.1 goes EOL, in which case we have to migrate to 3.0 and start the process over again.
Unlike with 4.7.2 where we just deploy the .net monthly rollups vis SCCM
Wouldn’t it be a good service to the development community to time the EOL to the imminent release of .Net Core 3.0? Especially as it appears there will potentially be some breaking changes from 2.2?
You say “.NET Core 2.2 is a Current releases”So shouldn’t it be mentioned here [https://dotnet.microsoft.com/], here [https://dotnet.microsoft.com/download] where it forces you onto 2.2, or even here [https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.2/2.2.2.md] where it contains supposed lifecysle news, but doesn’t.
You are effectively forcing all users onto a ‘support will be with only 3 months notice’ release, and without any hint of when the succeeding version will be released.
BTW your LTS support of ‘3 years’ isn’t really that because it takes months for it to be accepted by frameworks, third parties, docker layers, onto Azure etc. So it’s 2.5 years of ‘running platforms’ support ast best.
For enterprises that’s rubbish. But I know you don’t understand that because I’ve seen loads of comments by others to the same effect which you dismiss out of hand.
wiki style thanks you