-
Notifications
You must be signed in to change notification settings - Fork 132
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
Onboard maintenance-packages to source-build #4684
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
1 similar comment
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
I think that would mean that the maintenance-packages repo would need to be added to the VMR. |
Adding new repos to source-build is a repo owner responsibility - it is intended to be a self-servicing task. @dotnet/source-build will certainly provide guidance when needed. |
Not necessarily. There are other repos t hat are part of source build but not vmr. |
I'm not following. Source build works on the VMR so by definition, everything that is source-built must be part of the VMR. |
Closing per the discussion in dotnet/maintenance-packages#140. Summary: maintenance-packages is not required in SB. SBRP satisfies the requirements. |
Describe the Problem
The https://github.com/dotnet/maintenance-packages repository is being created as a place for packages that are still in support but no longer built elsewhere to continue to build.
The packages produced here will be referenced by packages that are part of the product on down-level platforms (eg: .NETFramework, .NETStandard).
Rather than copy the packages from here to SBRP, we should consider bringing maintenance-packages into source-build.
Describe the Solution
Onboard maintenance-packages into source-build and allow it's packages to flow into runtime and other repos. Note that maintenance-packages isn't expected to branch with the product, but instead be in perpetual LTS. As such its expected that
tip
will always be correct for all versions of .NET that are still in support.Additional Context
dotnet/runtime#108806
cc @ViktorHofer @carlossanlop
The text was updated successfully, but these errors were encountered: