I'm opening this issue here rather than https://github.com/dotnet/core-setup (host, platform abstractions), https://github.com/dotnet/corefx (RID-graph), or https://github.com/dotnet/sdk (runtime deps generation). The issue impacts all of these, including NuGet which was the source of the RID behavior as an opaque string.

The problems are as follows:

1. Existing supported OS releases a new version resulting in a new calculated RID and this RID cannot be used for restore/runtime-selection due to missing compatibility mappings until we update the RID-graph.
2. New linux distro comes along and should be treated as Linux-arch but is not.

This stems from the definition of RIDs being opaque strings and the only source of relationships being runtime.json / nuget.

Definitions:

• OS-name: specific name of an operating system or distro excluding version, eg: osx, ubuntu, win
• OS-version: specific version of an operating system or distro, eg: 10, 10.13, 7.4
• OS: a combination of OS-name and OS-version to represent a specific release of an operating system or distro.
• OS-family: a group of OS-name for the purpose of representing compatible behavior. eg: linux, unix

See also: https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/readme.md

The behavior I'd like to see is as follows:

1. For an OS that's already defined an OS-name relationship in the RID-graph, that relationship should hold for future OS-versions that aren't present in the RID graph. EG: osx.10.20-x64 should be considered compatible with osx-x64 (and all of its mappings in turn). If a RID is present in the graph explicitly this inference would not need to happen.
2. For an OS that's already defined an OS-version relationship in the RID-graph, that relationship should hold for future versions that aren't present in the RID graph. EG: osx.10.20-x64 should be considered compatible with osx.10.11-x64 (and all of its mappings in turn). If a RID is present in the graph explicitly this inference would not need to happen.
3. For an OS-name that does not appear in the RID-graph that OS-name could be treated as part of some default OS-family (potentially defined by the project).

I can imagine solutions to this that have changes in just the host and tooling, as well as changes that may require a NuGet update as well. I wanted to get a discussion going to understand if its something we can fix.

/cc @Petermarcu @davidfowl @anurse @emgarten @eerhardt @steveharter