NET Core 2.0 no longer support redhat 7.2 and OSX 10.11

[TingluoHuang]

Hi,

From the netcore 2.0 support OS doc, looks like Redhat only support 7.3+, OSX only support 10.12+. While in netcore 1.0, Redhat support 7.2 and OSX support 10.11.

I would like to know what's the motivation for no longer support those OS version in netcore 2.0, this makes adopt net core 2.0 a little bit hard for us, since i don't want to break customer who still in those OS version.

[richlander]

On macOS, we only support the latest versions. We consider macOS to be a developer OS and believe that adoption of new apple OSes is very quick.

@Petermarcu can comment on the Red Hat support.

This also sometimes happens because we need to take a dependency on a new API in order to implement a scenario.

[Petermarcu]

For OSX from a techincal angle, we moved to depend on the Apple Crypto stack to remove the OpenSSL dependency we had. The Apple Crypto libraries we needed to do this were introduced in 10.12.

Our lifecycle policy stated that we would only support the latest servicing level of each distro that is out when we shipped. That is what led to moving support on Linux from 7.2 to 7.3. We're considering moving back to 7.2 based on feedback.

[Petermarcu]

@leecow how do you want to track this discussion?

[richlander]

@Petermarcu are you specifically referring to the lifecycle policy part?

[TingluoHuang]

Thanks for the explanation. Today our vsts-agent produces 5 self-contained packages for different platforms. win7-x64, ubuntu16-x64, ubuntu14-x64, osx10.11-x64, redhat7.2-x64

We consider adopt netcore 2.0 since it will support on more OS and i can just build Linux-x64 for all linux flavors.

I guess if we still want to support customers to use vsts-agent on osx10.11 and redhat7.2. we need use netcore1.1 build those packages. win7-x64 (netcore2.0) Linux-x64 (netcore2.0) osx10.12-x64 (netcore2.0) redhat7.2-x64 (netcore1.1) osx10.11-x64 (netcore1.1)

[Petermarcu]

@richlander, yes, and the rhel7.2 decision for 2.0

[gortok]

My concern is primarily for large enterprises that don't upgrade quickly. ASP.NET Core is being used in scenarios where the customer has a months long process to upgrade their minor versions. For 'the cloud' this isn't a problem; but there are still self-hosted infrastructure places where it's important not to lose support so quickly.

Is ASP.NET Core just meant for the public 'cloud', or is it meant to work with the type of OS upgrades that larger enterprises do the way that .NET Framework works?

Keep in mind, officially DISA just released their STIGs for 7.1. (Has to be manually approved to be able to use 7.2 or 7.3):

http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx

[vcsjones]

Our lifecycle policy stated that we would only support the latest servicing level of each distro that is out when we shipped.

For what it's worth, I am a proponent of this model. It's easy to understand and predict, and often follows what other platforms and technology stacks are doing.

[richlander]

Is ASP.NET Core just meant for the public 'cloud', or is it meant to work with the type of OS upgrades that larger enterprises do the way that .NET Framework works?

ASP.NET Core is intended for both cloud and on-prem.

lifecycle

The main thing we want to avoid is supporting an operating system version that we know will go out of service while a given .NET Core release is in service. For example, if Ubuntu 16.10 will go out of service 12 months into a .NET Core release, we'd rather not support it from the start. We don't want to have to tell customers that we've dropped support for an OS version mid-way through a release of ours.

If an OS version for a supported distro will stay in service for our complete release and there is no technical reason why we need to drop support, then we should support it, particularly if customers are asking for it.

[TingluoHuang]

Few other thoughts/questions: Dotnet core has 2 parts, SDK and Runtime, SDK is for write a dotnet core app, and Runtime is for run the dotnet core portable app (not self-contained). Is the dropped support on OSX 10.11 in 2.0 only for SDK or it's for both SDK and Runtime?

If the support only dropped for SDK, i am fine with it, since it make sense say if you want to develop dotnet core app use new tooling you have to on latest OS.

However, if the support is also dropped for the runtime, i am confused. isn't the xplat story for coreclr is to run my dotnet core portable app on any version for any platform, as long as i use the right runtime for that platform.

Take example of node.js, node.exe on windows, node on linux/osx is the runtime for node.js. As long as i have the node runtime binary, i can run my node.js script on any platform. I haven't heard node.js drop OS supports for their runtime, they already at version 8.x.

Thanks, Ting

[bartonjs]

@TingluoHuang The runtime is what no longer has support for 10.11 (and therefore the SDK automatically no longer has support). We needed new functionality from 10.12 to make the cryptography stack not need OpenSSL.

I haven't heard node.js drop OS supports for their runtime

nodejs/node pull 5167 (avoiding the link 'cuz it feels weird) dropped support for Vista and prior. That was the first hit when I Google'd "node.js Windows support".

Occasionally one needs to change the minimum version to make use of new/different functionality.

[Petermarcu]

Note there is also a difference between Microsoft support and where the binaries will run. Microsoft has a support policy but taking RHEL 7.2 for example, Microsoft is only supporting RHEL 7.3 but the binaries should run just fine on RHEL 7.2.

As Jeremy said, for the OSX case, we actually had to take a new dependency only available in OSX 10.12.

[TingluoHuang]

Sorry about what i said about node never drop OS support. :D Well Vista is OS that released more than 10 years ago, however OSX 10.11 was only 3 years before. So the customer impact are different.

[TingluoHuang]

Another part that always bother me is all the prereq dotnet runtime needs per platform. like libuv/libcurl/openssl, etc. Is it possible to make dotnet runtime just like node, xcopy the runtime package, then dotnet myapp?

[Petermarcu]

It is possible. We'll produce a document on how to create a fully self contained application. @janvorli was working on that.

[TingluoHuang]

@Petermarcu cool, glad to hear that. will the doc to fully self contained app works for netcore 1.1 or it's only for 2.0?

[Petermarcu]

Its 2.0. We did work in the loader to support it. In essence, depending on your distro, you can copy the dependencies into your app in a certain folder and they will be loaded from there instead of looking for it from the package manager. Ideally someone in the community can help contribute the scripts to use for each distro to pick up the right stuff.

[Petermarcu]

@janvorli can you point to the doc you are writing here?

[Petermarcu]

Give this a try. Feedback is welcome on the doc. https://github.com/dotnet/core/blob/master/Documentation/self-contained-linux-apps.md

[Petermarcu]

I'm going to close this issue for now. If there are issues using the instructions, we should open a new issue.