release/3.1 add macOS11 to RID graph#42968
Conversation
|
test failure in System.Text.RegularExpressions is unrelated. |
| <RuntimeGroup Include="osx"> | ||
| <Parent>unix</Parent> | ||
| <Architectures>x64;arm64</Architectures> | ||
| <Versions>11;11.0</Versions> |
There was a problem hiding this comment.
Because you've made osx11 a separate entry it doesn't treat 11 as compatible with 10. Is that what we want?
There was a problem hiding this comment.
A similar discussion occurred with Tizen here: dotnet/runtime#38832
There was a problem hiding this comment.
can we make the x64 compatible while adding arm64 only for 11?
Or should we add arm64 for all versions even if we do not have implementation?
It seems like Tizien took the later approach, right?
Master change is dotnet/runtime#40644
There was a problem hiding this comment.
Third option would be to add functionality to special case as I suggested. It's up to you to define what you think the best behavior is. I'm not sure treating them as incompatible is correct, but I don't know enough about Apple's versioning and how their SDK's / platform API changes release-to-release. Perhaps some folks like @bartonjs or @akoeplinger might have an opinion.
There was a problem hiding this comment.
cc: @marek-safar since he opened the original issue. AFAK, we not use same bits build on 10.x and it seems to work find with few issues. I don't mind taking look at the generation but I'm not sure how do I ensure correctness.
There was a problem hiding this comment.
RIDs are all about what is most useful rather than what is correct. You can always have a case where things won't work, but that's not a reason to make them incompatible: folks can always include two assets to deal with an incompatibility. If it is more useful to treat osx11 as compatible with osx10 (so that folks can reuse a single asset the majority of the time) then that is how we should represent it.
There was a problem hiding this comment.
yes osx11 should definitely be compatible with osx10.
|
can I do something like @ericstj? e.g. make OSX parent of the new node. |
This defines a new RID prefix corefx/pkg/Microsoft.NETCore.Platforms/runtime.compatibility.json Lines 2349 to 2368 in 1c70f83 And corefx/pkg/Microsoft.NETCore.Platforms/runtime.compatibility.json Lines 2416 to 2427 in 1c70f83 This indicates that packages which use RIDs like osx10.n will no longer work with osx11.0. This may or may not be the right thing to do. I'm observing that its different than what we've done for every past version of osx, so we need to understand if that's right or not. |
|
that make sense @ericstj . Let's keep them together e.g. compatible unless proven otherwise. |
| <Architectures>x64</Architectures> | ||
| <Versions>10.10;10.11;10.12;10.13;10.14;10.15</Versions> | ||
| <Architectures>x64;arm64</Architectures> | ||
| <Versions>10.10;10.11;10.12;10.13;10.14;10.15;11;11.0</Versions> |
There was a problem hiding this comment.
Why are we adding both 11 and 11.0? Typically we only do one or the other because folks would expect them to be equivalent, however its actually directional (11.0 is compatible with 11, but 11 cannot use 11.0 assets). What value do we calculate?
There was a problem hiding this comment.
That is what @marek-safar asked for in original ticket.
As far as I can tell, dotnet still sees the build as 10.16
Runtime Environment:
OS Name: Mac OS X
OS Version: 10.16
OS Platform: Darwin
RID: osx-x64
Base Path: /Users/furt/Downloads/dotnet/sdk/5.0.100-rc.1.20418.3/
There was a problem hiding this comment.
I did more testing and OS report it self as 11.0
furt@macos-11 foo % sw_vers
ProductName: macOS
ProductVersion: 11.0
So I removed the 11 to be consistent with the rest. (dotnet still shows 10.16)
ericstj
left a comment
There was a problem hiding this comment.
Looks good. I've filed https://github.com/dotnet/arcade/issues/5998 to track being able to do this without adding the arch rids for older versions.
This is port of 5.0 change
fixes #40479