Simplify RID graph: keep floating and last versioned RIDs#125076
Simplify RID graph: keep floating and last versioned RIDs#125076richlander wants to merge 1 commit intomainfrom
Conversation
Softer approach to RID graph simplification. Instead of removing all versioned and distro-specific RIDs, this keeps: - All portable/base RIDs (any, unix, linux, win, etc.) - All floating (unversioned) OS RIDs (alpine, ubuntu, osx, etc.) - The last versioned RID for each OS family and its arch variants This reduces runtime.json from ~4600 lines (798 RIDs) to ~1500 lines (266 RIDs) while preserving a migration path for packages that reference the most recent versioned RIDs. Removed RIDs: all intermediate versioned RIDs (e.g. alpine.3.7 through alpine.3.17, ubuntu.14.04 through ubuntu.23.04, osx.10.10 through osx.12, etc.) Kept last versions include: alpine.3.18, android.32, centos.9, debian.12, fedora.39, freebsd.13, ios.15, osx.13, rhel.9, rocky.9, tizen.7.0.0, tvos.15, ubuntu.23.10, and others. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Tagging subscribers to this area: @agocke, @jeffschwMSFT, @elinor-fung |
|
What have you done to test this? Did you consider making this change in the VMR so that we can see if source build and phase2 product build are happy with the changes? |
|
Great questions. I haven't done anything to test it. My belief/understanding is that the fallout is compat. I can make this change in VMR. That didn't occur to me. My thinking -- perhaps naive -- is that any break there is a bug that needs to be fixed downstream. I'll apply this change to VMR. |
Softer approach to RID graph simplification. Instead of removing all versioned and distro-specific RIDs, this keeps: - All portable/base RIDs (any, unix, linux, win, etc.) - All floating (unversioned) OS RIDs (alpine, ubuntu, osx, etc.) - The last versioned RID for each OS family and its arch variants This reduces runtime.json from ~4600 lines (798 RIDs) to ~1500 lines (266 RIDs) while preserving a migration path for packages that reference the most recent versioned RIDs. Backport of dotnet/runtime#125076 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
It should be, but we might want to get that signal now. I think the VMR can give at least a sampling of those it won't run the SDK tests which I think might be equally valuable, but we don't have a good way to do that in PR. I don't have any objections to the PR itself, it's more "what's the fallout". I trust its well formed, but I am not reviewing for that. We used to have a generator for this that made it a bit easier to review the changes to the generator inputs. |
|
Understood. We're on the same page. |
I'd consider removing these too. The "modern" rid handling for a non-portable SDK depends on: |
|
I shared some data offline to show what packages are using the RIDs being discussed here. That provides a view of the producer side - we can't know what people use when building apps (consumer side) but a review of that data might help understand the compat impact of removing RIDs that might be used during restore. |
|
This proposal is on top of this break that we made 3 years ago: dotnet/docs#36466 That break has a workaround. You can see it in use: https://grep.app/search?q=%3CUseRidGraph%3Etrue%3C%2FUseRidGraph%3E The use of |
|
My understanding is; with Microsoft SDK:
Distro maintainers use 3rd option (graph gets generated during the source-bulid). If this is correct, then we don't need to change runtime.json for older/outdated SDK deployments to keep working. Otherwise, I misunderstood. 🙂 cc @elinor-fung |
|
The intent is to remove cruft from the product. The RID file is basically a wikipedia of old distros. I'd like to eventually delete the file. I grasp, as you are suggesting, that its also enable compatibility for old assets on nuget.org, otherise they are basically unusable. Consumers can either use old SDKs, insert their own RID graph, or user a newer version. Some of the libraries may be abandoned. It's OK to have to take extra steps to use abandoned software. |
|
Here is the data we collected, sorted by package count with a cutoff at 10 packages. The primary data I see is that we should consider bringing some Ubuntu RIDs back. On that note, I see that Ubuntu 23.10 is the latest/retained Ubuntu RID. That's not super useful. If we follow the data, we could replace 23.10 with 18.04 and that would solve most of the problem.
|
Ah, yes. I think users should use APIs like It doesn't seem a mechanism that is relied on for splitting nuget packages either. Searching for latest Ubuntu LTS shows only 7 packages (by 5 users): https://www.nuget.org/packages?q=ubuntu.24.04-x64. |
|
That's a good point. As I hinted at, my hope would be to make this change for 11 and the delete most of the infra for 12. |
Replaces: #123161
Softer approach to RID graph simplification. Instead of removing all versioned and distro-specific RIDs, this keeps:
This reduces runtime.json from ~4600 lines (798 RIDs) to ~1500 lines (266 RIDs) while preserving a migration path for packages that reference the most recent versioned RIDs.
We can do more cleanup later. This approach is a much safer starting point with easier migration guidance. It's also more defensible.
Removed RIDs: all intermediate versioned RIDs (e.g. alpine.3.7 through alpine.3.17, ubuntu.14.04 through ubuntu.23.04, osx.10.10 through osx.12, etc.)
Kept last versions include: alpine.3.18, android.32, centos.9, debian.12, fedora.39, freebsd.13, ios.15, osx.13, rhel.9, rocky.9, tizen.7.0.0, tvos.15, ubuntu.23.10, and others.