Add missing OL releases to RID graph

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.

[Mr-Tao]

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

[ghost]

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

Issue Details

---

In PR, I’ve tried to address comments that #66783 received.

I’m very much in favour of adding only major versions to the RID graph, as @omajid suggested in #66783 (comment). In Oracle Linux, we have been adding minor versions for Dotnet versions up to 7.9 and 8.7 so far.

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. 🤔 I don’t know for sure, so I have kept minor versions.

But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm) #66783 (comment)

I tried generating the graph without adding respective rhel RIDs. The task failed as expected, complaining about missing parents.

Author:	Mr-Tao
Assignees:	-
Labels:	area-Host
Milestone:	-

[omajid]

I am happy there are no minor-version RIDs for OL 9 🎉

Since all minor versions should be compatible, dropping all minor versions from the graph may be possible. But I see that this didn’t happen with rhel minor versions already present in the graph, which lets me think about whether there are potential repercussions from dropping them. thinking I don’t know for sure, so I have kept minor versions.

I think it's a compatibility concern. If a user has used the RID in the past and we drop the RID in the graph, that might break applications, or at prevent the build/publish commands that were previously working from continuing to work.

I don't know if these concerns still apply when adding it to repo here, because those RIDs weren't present previously so they wouldn't be treated as "removed"/"breaking" if they just not added.

So maybe we can leave out the minor version RIDs from this PR? Will this really impact customers given the RID graph on nuget.org didn't have these versions already?

Anyway, I wont block the addition of RHEL minor version IDs here. I don't see a harm.

[agocke]

While we're contemplating deprecating the whole RID graph (#83246), I'm going to close this for now. We can re-open if we end up not going in that direction

[Mr-Tao]

Thanks for taking the time to review the PR, @agocke. I like the idea of getting rid of RIDs very much. We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9. At the same time we still need to maintain the set of RIDs added on OL8 and OL7 to be able to build dotnet 3, 6 and 7.

By including this change the Oracle Linux support would get on par with support for RHEL, Rocky and others. The change also does not add any complexity to the process of deprecation of RIDs when and if the time comes.

[ViktorHofer]

@richlander until we execute on the RID plan changes, should we keep accepting these changes or close them?

[tmds]

We are already following Red Hat by not introducing any more RIDs for minor versions of Oracle Linux 9.

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

[ViktorHofer]

ping @richlander regarding my above question

[carlossanlop]

Reopening this PR to continue the conversation. I closed the release/6.0 PR version of this change, since we would first need to merge the main version before taking a servicing version: #83681

Ping @richlander

[Mr-Tao]

You can't omit these minor versions until you update .NET to ignore the minor.

That means adding code here:

runtime/src/native/corehost/hostmisc/pal.unix.cpp

Lines 766 to 770 in 31e4f40

	pal::string_tnormalize_linux_rid(pal::string_t rid)
	{
	pal::string_trhelPrefix(_X("rhel."));
	pal::string_talpinePrefix(_X("alpine."));
	pal::string_trockyPrefix(_X("rocky."));

(and similar for .NET 6).

Thanks for pointing this out, @tmds. Do you think that there’s anything else that needs to be added besides this change? https://github.com/dotnet/runtime/pull/81115/files#diff-b2bd8511e88327d8f146bc460e79182cc6826e2b90039dffc4f5f89c5467d12a

[omajid]

With the addition of changes to pal.unix.cpp, are these still necessary? What happens if you don't add all the new 8 RIDs to ol and rhel?

[Mr-Tao]

I suppose that dotnet would build fine. If this is safe, why does RedHat still keep minors for 8? Could this be an issue for customer applications? 🤔

[omajid]

If this is safe, why does Red Hat still keep minors for 8

It's mostly due to backwards compatibility. We added them to the RID graph for 8 before we finished all the fixes (eg, the pal.unix.cpp stuff), and now we can't remove them.

No one should be depending on the minor versions. It makes everyone's life harder.

[MichaelSimons]

@agocke, @carlossanlop, @richlander - What is the plan for requests like this to update the RID graph? I know there is the proposed RID plan. What is the timeline for implementing it? This issue is affecting folks wanting to source-build .NET.

[agocke]

RID changes are in and breaking change is filed: https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/8.0/rid-asset-list

RID graph is now frozen.