Add missing RIDs for all supported OSes #26439

bording · 2018-01-19T01:37:51Z

This adds all of the RIDs that were identified as missing in #23699. This covers all of the OSes listed in https://github.com/dotnet/core/blob/master/release-notes/2.0/2.0-supported-os.md

In addition to there being versions missing for existing RIDs, there was no RID defined for SUSE Enterprise Linux at all, so I added that as well, mirroring the opensuse section.

@weshaggard I wasn't sure what the correct branch for this should be, so I went ahead and based it against master. Let me know if it should be something else, and I'll fix it up.

dnfclas · 2018-01-19T01:38:02Z

All CLA requirements met.

weshaggard · 2018-01-19T01:47:30Z

pkg/Microsoft.NETCore.Platforms/runtimeGroups.props

@@ -111,6 +118,12 @@
      <Versions>16.04;16.10</Versions>
      <TreatVersionsAsCompatible>false</TreatVersionsAsCompatible>
    </RuntimeGroup>
+    <RuntimeGroup Include="ubuntu">


Why aren't these versions just added to the 16.x versions of Ubuntu?

Because of how the file was originally structured. It's using <TreatVersionsAsCompatible>false</TreatVersionsAsCompatible> and has the ubuntu releases are compatible on major versions comment. So I assume it's split to maintain that.

Actually TreatVersionsAsCompatible=false makes all versions independent. The reason for the split between 14+15 and 16 was that 16 added a new architecture: arm64. Since you aren't adding a new arch you can just include this with the 16.x versions. You can try it and examine the diff to prove that it doesn't make a difference in the generated files.

@ericstj I'll update the PR with that change then.

Also I think that comment ubuntu comment about major versions is incorrect 🙁. I double checked and this was true before my change to autogenerate as well. If you'd like you can delete it or correct it to say all ubuntu versions are independent.

weshaggard · 2018-01-19T01:48:35Z

@richlander @Petermarcu @leecow can you guys please take a look to see if there are other distro's or versions we need to add to the RID graph?

@weshaggard I wasn't sure what the correct branch for this should be, so I went ahead and based it against master. Let me know if it should be something else, and I'll fix it up.

master branch is the correct one at this point.

bording · 2018-01-19T01:51:21Z

master branch is the correct one at this point.

Possibly too soon to ask, but what are the odds of these changes also making it into a 2.0.x servicing release? It would be nice to not have to wait for 2.1.

ericstj · 2018-01-19T16:28:52Z

pkg/Microsoft.NETCore.Platforms/runtimeGroups.props

+      <TreatVersionsAsCompatible>false</TreatVersionsAsCompatible>
+    </RuntimeGroup>
+
+    <RuntimeGroup Include="sles">


Make sure you are intentionally treating these as independent versions, eg: 12.2 shouldn't import 12.1. If that shouldn't be true then remove <TreatVersionsAsCompatible>false</TreatVersionsAsCompatible>.

What should I be investigating to determine if they are "compatible" or not? It's not clear to me what that distinction is based on.

This is related to my question below for Eric and Wes. Would be great if we could simply define sles 12. This is how the distro owners think of the major version 'band'. 12.2 is actually "12 SP2" and comes with the inherent compat promises of a service pack. FWIW SP3 is the latest SLES release.

In the past we've left it up to the folks who know the most about the distros (ideally contributors to those). For example: red hat goes out of there way to make their minor releases compatible across for a single major version (see https://access.redhat.com/articles/rhel-abi-compatibility), windows does so across all versions, whereas others like ubuntu do not and we've had a history of breaks when folks try to reuse binaries.

Ultimately its a bit of a loaded question: what is compatibility? You can read through issues that mention binary compatibility to see some of the past discussion on the topic. My preference is to opt for compatibility since it enables something that is otherwise not possible, see https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/readme.md#version-compatibility.

It appears that SLES has a similar compatibility guarantees for releases within a major version: https://www.suse.com/partners/isv/porting_and_migration/

I'll remove the <TreatVersionsAsCompatible>false</TreatVersionsAsCompatible> line.

leecow · 2018-01-19T16:35:31Z

@weshaggard , @ericstj - Why do we need to include minor versions for rhel, mint, opensuse and sles? If there's not technical reason for doing so, treating them in a manner similar to debian.8 and debian.9 (which also ship regular minor updates) would limit the churn to this file and conceivably make things a bit more resilient.

@bording - agreed that this should also go to 2.0.

Couple of version comments

Fedora 25 went eol last month
Ubuntu 17.04 went eol 1/13
OpenSUSE 42.2 will be going eol next week
I'm OK adding these so the to get caught up but we will soon be removing all from our builds and testing.

bording · 2018-01-19T16:59:46Z

Couple of version comments

@leecow Because they were once supported, I felt it made sense to add the missing ones from your list for completion vs. having a strange gap in the versions.

Even if a distro goes out of support, would you ever remove items from the runtime file? It seems like removing something could break people, for example if someone's authored a NuGet package that has per-RID content.

leecow · 2018-01-19T17:18:49Z

Even if a distro goes out of support, would you ever remove items from the runtime file?

Nope, only from our build and test infrastructure. Anything related to public functionality would remain intact.

danmoseley · 2018-01-19T18:58:23Z

cc @joshfree

joshfree · 2018-01-19T19:24:08Z

pkg/Microsoft.NETCore.Platforms/runtime.json

+        "ubuntu-x86"
+      ]
+    },
+    "ubuntu.17.10-x86-corert": {


Could you also go ahead and add ubuntu.18.04 proactively?

Similarly if you wouldn't mind, Fedora 28 and Mint 19 all come out around the same time and should be included in the 2.1 RID graph

Sure, I can add those. Any others that make sense to add now?

Thanks @bording. With those additions you'll have added all of the supported distro versions through the ~May 2018 time frame.

Near the end of 2018, we'll need to add the supported H2 2018 releases {Ubuntu18.10 / Mint 19 / SLES 15 / Fedora 29} to the master branch around that time; as well as stand up the appropriate build and test infra for those releases.

bording · 2018-01-20T01:02:01Z

I've pushed up changes that I believe address all comments so far.

While looking into SLES compatibility guarantees, I realized there is a similar issue for debian. The way I've added version 9 means they are being treated as compatible. However, I can't find anything specific online to indicate if this is okay or not like I could for SLES.

Does anyone know how I should handle that one? I see that https://www.microsoft.com/net/learn/get-started/linuxdebian has separate package feeds for them, so does that mean it's best to treat them as separate?

ericstj · 2018-01-22T16:33:49Z

pkg/Microsoft.NETCore.Platforms/runtimeGroups.props

+    <RuntimeGroup Include="linuxmint.19">
+      <Parent>ubuntu.18.04</Parent>
+      <Architectures>x64</Architectures>
+      <Versions></Versions>


No versions? I wonder if we should be listing the versions as 18, 18.1, 18.2, then 19 (in a seperate item). I can't recall why I put the major version in the include statement initially. If it works without a diff move the the major versions to the version metadata.

@ericstj I did try doing it that way, but because there are different parents for each major, it failed when trying to create the "linuxmint" RID.

I could go ahead and add some versions, but I didn't do that initially because it felt it was speculating too far into upcoming releases.

I see. That's why I must have done it, I remember now. Can we add a comment here to explain? I'm fine not adding 'dot' versions if none exist yet (not even 0?).

The first release of a linux mint major is just the major, without a 0, at least for all the recent versions: https://en.wikipedia.org/wiki/Linux_Mint_version_history

I'll add a comment to explain.

ericstj · 2018-01-22T16:58:20Z

I'm not sure about debian, perhaps @eerhardt or @janvorli might be able to comment on the compatibility of these major releases.

weshaggard · 2018-01-22T19:59:46Z

Possibly too soon to ask, but what are the odds of these changes also making it into a 2.0.x servicing release? It would be nice to not have to wait for 2.1.

I don't know of any plans to take this into the 2.0 branch at this point. @joshfree do we need any of these RID updates for 2.0 servicing?

However assuming we get https://github.com/dotnet/core-setup/issues/1846 addressed you can simply reference the latest prerelease version of Microsoft.NETCore.Platforms package in your application to get the graph merged in.

weshaggard

LGTM Thanks for updating @bording. Once you add the one comment as requested by @ericstj we can merge this change.

bording · 2018-01-22T20:12:00Z

@weshaggard I should be able to add the comment some time today, but I do still have the outstanding question about debian compatibility that I'd like to get an answer on before this gets merged.

janvorli · 2018-01-22T22:56:57Z

@bording - regarding the Debian 9 vs 8 compatibility. I am not sure about one thing. I know there was a change in OpenSSL libraries. Debian 8 had libssl.so.1.0.0 while Debian 9 has libssl.so.1.0.2 (I am talking about the SO name). So there is no official libssl.so.1.0.0 package for Debian 9 and apps / shared libraries that are linked against it would break unless someone installs a libssl.so.1.0.0 from the Debian 8 (which is possible). W.r.t. that, do you regards Debian 8 and 9 still as compatible or not?

bording · 2018-01-22T23:09:23Z

@janvorli I know for the scenario that lead me to investigate these missing RIDs in the first place, that would be enough for me to consider them not compatible because I'd need to ship separate libraries for each distro.

Based on that, I think I should adjust the PR to not treat them as compatible. Anyone have an objection?

weshaggard · 2018-01-22T23:16:02Z

Based on that, I think I should adjust the PR to not treat them as compatible. Anyone have an objection?

Sounds good to me. We essentially need one primary example of an incompatibility that requires us to pick different assets to deploy to mark them as incompatible.

bording · 2018-01-22T23:34:59Z

I've now made all the changes that I'm aware needed to be made. @ericstj Let me know if the comments I added for linux mint are okay or if there's something you'd like me to tweak..

weshaggard · 2018-01-22T23:59:39Z

pkg/Microsoft.NETCore.Platforms/runtimeGroups.props

@@ -61,7 +62,7 @@
    <RuntimeGroup Include="linuxmint.19">
      <Parent>ubuntu.18.04</Parent>
      <Architectures>x64</Architectures>
-      <Versions></Versions>
+      <Versions></Versions><!-- Empty because there are no point releasse yet -->


typo: releasse -> releases

Oops! will fix.

Pushed up a revised commit.

weshaggard · 2018-01-23T16:52:56Z

test Windows x64 Debug Build
test Windows x86 Release Build

weshaggard · 2018-01-23T17:25:41Z

CI legs failing with known issue https://github.com/dotnet/corefx/issues/26531.

weshaggard · 2018-01-23T17:26:52Z

Thanks a lot for your help @bording in updating the RIDs.

bording · 2018-01-23T23:26:18Z

So what's the final verdict for including the runtime.json updates in a servicing release? I know earlier that @leecow thought it should happen.

joshfree · 2018-01-24T17:55:36Z

@bording yes, please feel free to submit the PR against the release/2.0.0 branch.

/cc'ing @ianhays who can help shepherd this through our servicing release process.

* Add missing versions * Add missing RID * Update runtime files * Address PR feedback for ubuntu RID * Treat minor versions of SLES as compatible * Add upcoming releases * Move SLES definition to maintain alphabetization of file * Treat debian versions as not compatible * Add linux mint comments Commit migrated from dotnet/corefx@6bfbf57

bording added 3 commits January 18, 2018 20:30

Add missing versions

6d17219

Add missing RID

d4ee181

Update runtime files

b9c64a9

weshaggard reviewed Jan 19, 2018

View reviewed changes

weshaggard requested a review from ericstj January 19, 2018 01:50

ericstj reviewed Jan 19, 2018

View reviewed changes

joshfree reviewed Jan 19, 2018

View reviewed changes

bording added 4 commits January 19, 2018 19:09

Address PR feedback for ubuntu RID

5e874cb

Treat minor versions of SLES as compatible

359c88f

Add upcoming releases

f818d7e

Move SLES definition to maintain alphabetization of file

7534f4d

karelz added the area-Infrastructure-libraries label Jan 20, 2018

karelz assigned bording, ericstj and weshaggard Jan 20, 2018

ericstj reviewed Jan 22, 2018

View reviewed changes

ericstj approved these changes Jan 22, 2018

View reviewed changes

joshfree approved these changes Jan 22, 2018

View reviewed changes

weshaggard approved these changes Jan 22, 2018

View reviewed changes

Treat debian versions as not compatible

18e772c

weshaggard reviewed Jan 22, 2018

View reviewed changes

Add linux mint comments

5829f53

ericstj approved these changes Jan 23, 2018

View reviewed changes

weshaggard merged commit 6bfbf57 into dotnet:master Jan 23, 2018

bording deleted the update-rids branch January 24, 2018 23:48

bording mentioned this pull request Jan 24, 2018

Update runtime.json to include missing RIDs #26577

Merged

karelz added this to the 2.1.0 milestone Feb 4, 2018

bording mentioned this pull request Apr 14, 2018

Use docker to build for multiple distros libgit2/libgit2sharp.nativebinaries#51

Merged

Add missing RIDs for all supported OSes #26439

Add missing RIDs for all supported OSes #26439

Conversation

bording commented Jan 19, 2018

dnfclas commented Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

bording Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericstj Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

weshaggard commented Jan 19, 2018

bording commented Jan 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericstj Jan 19, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leecow commented Jan 19, 2018 • edited Loading

bording commented Jan 19, 2018

leecow commented Jan 19, 2018

danmoseley commented Jan 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bording commented Jan 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericstj commented Jan 22, 2018

weshaggard commented Jan 22, 2018

weshaggard left a comment

Choose a reason for hiding this comment

bording commented Jan 22, 2018

janvorli commented Jan 22, 2018

bording commented Jan 22, 2018 • edited Loading

weshaggard commented Jan 22, 2018

bording commented Jan 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weshaggard commented Jan 23, 2018

weshaggard commented Jan 23, 2018

weshaggard commented Jan 23, 2018

bording commented Jan 23, 2018 • edited Loading

joshfree commented Jan 24, 2018

dnfclas commented Jan 19, 2018 •

edited

Loading

bording Jan 19, 2018 •

edited

Loading

ericstj Jan 19, 2018 •

edited

Loading

ericstj Jan 19, 2018 •

edited

Loading

leecow commented Jan 19, 2018 •

edited

Loading

bording commented Jan 22, 2018 •

edited

Loading

bording commented Jan 23, 2018 •

edited

Loading