Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); Remove EOL Linux versions from runtime graph. by tmds · Pull Request #82223 · dotnet/runtime · GitHub
Skip to content

Remove EOL Linux versions from runtime graph. - #82223

Closed
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol
Closed

Remove EOL Linux versions from runtime graph.#82223
tmds wants to merge 5 commits into
dotnet:mainfrom
tmds:rid_eol

Conversation

@tmds

@tmdstmds commented Feb 16, 2023

Copy link
Copy Markdown
Member

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

@ghostghost added area-Infrastructure-libraries community-contribution Indicates that the PR has been added by a community member labels Feb 16, 2023
@ghost

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

And, make it unnecessary to define RHEL minors by changing the Oracle Linux definitions.

@wfurt@ViktorHofer@omajid ptal.

Author:tmds
Assignees:-
Labels:

area-Infrastructure-libraries, community-contribution

Milestone:-

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alpine 3.13 and previous are EOL 2022-11-01. (https://www.alpinelinux.org/releases/)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

openSuse 15.3 is EOL 2022-12-31, openSuse 42.3 is EOL 2019-07-01 (https://en.opensuse.org/Lifetime#Discontinued_distributions)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed versions are EOL 2022-07-14 and before (https://wiki.ubuntu.com/Releases).

And make it unnecessary to define RHEL minors by
changing the Oracle Linux definitions.
<Parent>linux</Parent>
<Architectures>x64;arm64</Architectures>
<Versions>23;24;25;26;27;28;29;30;31;32;33;34;35;36;37;38</Versions>
<Versions>36;37;38</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fedora 35 and previous are EOL 2022-12-13 (https://docs.fedoraproject.org/en-US/releases/eol/).

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to list out the minors because the host doesn't map them to a major, like it does for RHEL.
The previous definition required those minors to also be defined for RHEL.
This updated definition makes that unnecessary.

@omajid

Copy link
Copy Markdown
Member

My understanding was that removing RIDs is breaking backwards compatibility and simply not acceptable. If that's wrong, then cleaning up the RID graph sounds like a great idea!

<Architectures>x64</Architectures>
<Versions>8;8.0</Versions>
<ApplyVersionsToParent>true</ApplyVersionsToParent>
<Versions>0;1;2;3;4;6;6</Versions>

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<Versions>0;1;2;3;4;6;6</Versions>
<Versions>0;1;2;3;4;5;6</Versions>

new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel.9-arm64" })
new RuntimeDescription("rhel.10", new[] { "rhel" }),
new RuntimeDescription("rhel.10-x64", new[] { "rhel.10", "rhel-x64" }),
new RuntimeDescription("rhel.10-arm64", new[] { "rhel.10", "rhel-arm64" })

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test changes are due combining the rhel 8 and 9 versions with TreatVersionsAsCompatible=false.

Alternatively, I can keep the split elements for 8 and 9 (without TreatVersionsAsCompatible), and only remove the minors.
That has no effect on the generated files, but the test can stay the same then.

@wfurt

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases. While they may be EOS or EOL people still may use them. That also keeps it more consistent with old .NET releases.
cc: @ericstj@jkotas for more thought.

@jkotas

Copy link
Copy Markdown
Member

AFAIK we do not remove olde releases.

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

@tmds

tmds commented Feb 16, 2023

Copy link
Copy Markdown
MemberAuthor

Yes, it has been our policy so far. In particular, we are worried about nuget packages that are targeting out-of-support runtimes or OSes, but otherwise work just fine.

I think there aren't many of these nuget packages, but I'm just guessing.

Should .NET 8 be able to consume assets that were built for a specific distro that EOLed one or several years ago?

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

@jkotas

Copy link
Copy Markdown
Member

cc @richlander

I agree with you that the current RID graph growth is not sustainable. It is why we have been looking into deprecating it in parallel conversion.

This change gives us a bit more breathing room in near term. As you have said, we should understand how many packages are potentially impacted. @marklio Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

@am11

am11 commented Feb 16, 2023

Copy link
Copy Markdown
Member

This graph is flattened in a list that is added to the runtime (Microsoft.NETCore.App.deps.json). For .NET 7, the list is over 2k lines.

Also during each app's startup, host deserializes JSON contents. e.g. on Arch Linux x64, corehost trace shows that the non-portable build is working with 22 lines (left) vs. portable build which is working with 2160 lines (right): https://www.diffchecker.com/hBye38Tc/.

Would it be possible to get insights into how many packages on nuget.org target specific Unix distros (e.g. Ubuntu)?

+1, and if possible, also how many are using versioned RID (base OS: linux-x64 vs. distro-specific: ubuntu-x64 vs. distro-specific & versioned: ubuntu.18.04-x64.

ps - while typing this, just noticed that versioned RID for windows has different format: win10-x64 instead of win.10-x64 like all other platforms with versions in the graph. 😕

@richlanderrichlander mentioned this pull request Mar 10, 2023
@ericstjericstj added the breaking-change Issue or PR that represents a breaking API or functional change over a previous release. label Mar 27, 2023
@ghostghost added the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Mar 27, 2023
@ghost

Copy link
Copy Markdown

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

  1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
  2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

@tmds

tmds commented Apr 13, 2023

Copy link
Copy Markdown
MemberAuthor

I'm going to close this. It can always be reopened later, if needed.

@tmdstmds closed this Apr 13, 2023
@ghostghost locked as resolved and limited conversation to collaborators May 13, 2023
@jeffhandleyjeffhandley removed the needs-breaking-change-doc-created Breaking changes need an issue opened with https://github.com/dotnet/docs/issues/new?template=dotnet label Apr 4, 2026
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Infrastructure-librariesbreaking-changeIssue or PR that represents a breaking API or functional change over a previous release.community-contributionIndicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants

@tmds@omajid@wfurt@jkotas@am11@jeffhandley@carlossanlop@ericstj