Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET 6: Alpine backporting #3087

Closed
13 of 18 tasks
ayakael opened this issue Oct 25, 2022 · 10 comments
Closed
13 of 18 tasks

.NET 6: Alpine backporting #3087

ayakael opened this issue Oct 25, 2022 · 10 comments
Assignees
Labels
area-patch-removal Removing patches for contributing repos from source-build

Comments

@ayakael
Copy link

ayakael commented Oct 25, 2022

Issue tracker for Alpine patch backporting for .NET 6

Goals

Backport all patches currently used by Alpine's dotnet6 package

Clang patches

Source-build related patches

s390x / ppc64le related patches

arm related patches

Non-portable build patches

@ayakael
Copy link
Author

ayakael commented Oct 26, 2022

@omajid I went ahead and made a PR for removing ILStrip dependency on Mono, seeing as how it doesn't seem like you've upstreamed it: dotnet/runtime#77503

Also, should I make a PR for the msbuild stuff?

Finally, for roslyn, how do I go about backporting the patch given lack of release/6.0 branch?

@omajid
Copy link
Member

omajid commented Oct 27, 2022

Also, should I make a PR for the msbuild stuff?

See #2618 (comment). We could continue carrying this patch locally, but sharing it would be better.

Finally, for roslyn, how do I go about backporting the patch given lack of release/6.0 branch?

That's a good question. If we look in dotnet/installer's release/6.0.1xx branch, it's using roslyn commit 487283bcd8d66693091f2800dcf1c8ae37cccdee: https://github.com/dotnet/installer/blob/5700aea798f6940ad4a713b0bc3b31bdf6e8efd8/eng/Version.Details.xml#L144-L148

$ cd roslyn
$ git branch --contains 487283bcd8d66693091f2800dcf1c8ae37cccdee
* main
  release/dev17.4

So, it sounds like we should make the PR against the release/dev17.4 branch? Hopefully a roslyn maintainer can correct us if we get it wrong.

@MichaelSimons MichaelSimons added area-patch-removal Removing patches for contributing repos from source-build and removed untriaged labels Oct 27, 2022
@ayakael
Copy link
Author

ayakael commented Oct 29, 2022

Also, should I make a PR for the msbuild stuff?

See #2618 (comment). We could continue carrying this patch locally, but sharing it would be better.

Finally, for roslyn, how do I go about backporting the patch given lack of release/6.0 branch?

That's a good question. If we look in dotnet/installer's release/6.0.1xx branch, it's using roslyn commit 487283bcd8d66693091f2800dcf1c8ae37cccdee: https://github.com/dotnet/installer/blob/5700aea798f6940ad4a713b0bc3b31bdf6e8efd8/eng/Version.Details.xml#L144-L148

$ cd roslyn
$ git branch --contains 487283bcd8d66693091f2800dcf1c8ae37cccdee
* main
  release/dev17.4

So, it sounds like we should make the PR against the release/dev17.4 branch? Hopefully a roslyn maintainer can correct us if we get it wrong.

Ulrich beat me to the punch, they backported the patch a week ago. Thanks @uweigand!

@ayakael
Copy link
Author

ayakael commented Oct 29, 2022

Actually, what am I talking about?! They fixed the bug a week ago + 1 year. I think we need to update our Version.Details.Xml to pull latest commit from dev/17.4

@ayakael
Copy link
Author

ayakael commented Nov 2, 2022

dev/17.4 is way too new for release/6.0.1xx, and there's no branch dedicated to release/6.0.1xx. @MichaelSimons Is this something that we can propose to the roslyn devs? I see they have a release/6.0.1xx-rc2 branch. It'd be nice to have the option to maintain servicing branches in the future.

If not, is this something we could ship within the source-build patches for release/6.0.1xx of installer?

@ayakael
Copy link
Author

ayakael commented Nov 8, 2022

Would anyone know when we will jump to a new feature version (like 6.0.4xx) so I can get ahead of the curve and backport the proper patches to avoid regressions?

@MichaelSimons
Copy link
Member

Would anyone know when we will jump to a new feature version (like 6.0.4xx) so I can get ahead of the curve and backport the proper patches to avoid regressions?

Source-build will only support the 6.0.1xx feature band. This is documented here. FWIW, we are working on supporting all feature bands in the future.

@ayakael
Copy link
Author

ayakael commented Nov 8, 2022

Would anyone know when we will jump to a new feature version (like 6.0.4xx) so I can get ahead of the curve and backport the proper patches to avoid regressions?

Source-build will only support the 6.0.1xx feature band. This is documented here. FWIW, we are working on supporting all feature bands in the future.

Copy that, so for .NET 8 we should expect all feature bands to be supported?

@ayakael
Copy link
Author

ayakael commented Nov 16, 2022

Considering dotnet/roslyn#65174, roslyn dev teams won't be creating a branch for SDK releases. Can we then integrate the roslyn patch within source-build?

@ayakael
Copy link
Author

ayakael commented Jan 9, 2024

Closed now that patched are mostly backported

@ayakael ayakael closed this as completed Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-patch-removal Removing patches for contributing repos from source-build
Projects
Archived in project
Development

No branches or pull requests

3 participants