RID work for macOS 12

[wfurt]

Note this is weird as with 11.0 the naming has changed as well as and OS was lying us of a while about actual os version, reporting 10.17 instead. Since we seems to use updated SDK this does not seems to be necessary any more so as the game of mapping kernel to OS version.

It seems like starting with 11.0, the releases we used to track as 10.x are really now major releases and the 'x' becomes insignificant. So I changed the 12 rid to match Win & RHEL.

We may do more cleanup for Environment.OSVersion but since that seems to war I'll do it separately if needed.
kern.osproductversion was missing in some very old OS X versions but it is available in 10.13 and later.

[ghost]

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Note this is weird as with 11.0 the naming has changed as well as and OS was lying us of a while about actual os version, reporting 10.17 instead. Since we seems to use updated SDK this does not seems to be necessary any more so as the game of mapping kernel to OS version.

It seems like starting with 11.0, the releases we used to track as 10.x are really now major releases and the 'x' becomes insignificant. So I changed the 12 rid to match Win & RHEL.

We may do more cleanup for Environment.OSVersion but since that seems to war I'll do it separately if needed.
kern.osproductversion was missing in some very old OS X versions but it is available in 10.13 and later.

Author:	wfurt
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[wfurt]

ping. anybody brave?

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Note this is weird as with 11.0 the naming has changed as well as and OS was lying us of a while about actual os version, reporting 10.17 instead. Since we seems to use updated SDK this does not seems to be necessary any more so as the game of mapping kernel to OS version.

It seems like starting with 11.0, the releases we used to track as 10.x are really now major releases and the 'x' becomes insignificant. So I changed the 12 rid to match Win & RHEL.

We may do more cleanup for Environment.OSVersion but since that seems to war I'll do it separately if needed.
kern.osproductversion was missing in some very old OS X versions but it is available in 10.13 and later.

Author:	wfurt
Assignees:	-
Labels:	area-Host
Milestone:	-

[marek-safar]

Are you planning to backport this to 6.0?

[wfurt]

yes. I think this would qualify for servicing. I will get ready separate change for 5.x

[marek-safar]

@agocke please speed up the review

[agocke]

The precedent we're setting with Windows 11 is that we match the OS product version, not the marketing version. It looks to me like that's what this PR is doing -- that the OS is reporting a new product version. Is that correct?

[wfurt]

There is really no marketing version here. With this, we should match what sw_vers reports and what you see one the About dialog @agocke.

There are two parts: In the old days, there was no convent API to get that so we had mapping from kernel version to OS version. AFAIK that is no longer needed.
For bits but agains older SDK the OS would lie and report "compact" version eg. 10.x instead of 11.0 and 12.0. That impacts 5.0 (will need separate change) but not 6.0 as far as I can tell.

And there is the "normal" rid work to add 12.0 to the graph.

[vitek-karas]

I personally don't know versioning story around macOS.

On Windows we decided (See #58588) that there's little point in introducing win11 RIDs. Core of the reasoning is that OS still returns 10 as the major version and that we don't introduce new RIDs for Windows Server releases either.

If on macOS the OS actually returns the new version and it makes a material difference, then we should add a new RID (I don't know this though). I guess this is just a "small pushback" to make sure that we need to add the new RID (trying to keep the always growing list of RIDs in check).

[wfurt]

We already made the leap with 11.0 @vitek-karas. (with 5.0 & ARM based machines)

[agocke]

It looks like Big Sur reported itself as 11.0, except if you set SYSTEM_VERSION_COMPAT=1. I don't think we should operate based on compat versions, so by that metric, the system version was 11.0 and Monterey should be 12.0.

Change LGTM

[vitek-karas]

OK - makes sense 😄

[wfurt]

I verified the outcome with recent builds on two separate machines using dotnet --info

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  12.0
 OS Platform: Darwin
 RID:         osx.12-x64
 Base Path:   /Users/furt/dotnet-7/sdk/7.0.100-alpha.1.21518.14/


Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.6
 OS Platform: Darwin
 RID:         osx.11.0-arm64
 Base Path:   /Users/furt/dotnet-7/sdk/7.0.100-alpha.1.21528.2/

First one is my 12.0 VM. It shows the expected RID matching the change.
Second system us my ARM64 macBook running 11.6. It shows the same legacy osx.11.0 as it used to before the change (because we did not add more rids for the 11.x releases)

Unless there are concerns I'll pick up all the changes and I'll create servicing request for 6.0.x.