Skip to content

Update maintenance-packages pruning versions #49092

New issue

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

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

Already on GitHub? # to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ericstj
Copy link
Member

@ericstj ericstj commented May 21, 2025

Fixes #47314

This updates pruning versions for maintenance-packages. We do so only on frameworks where they were previously pruning the version just before the maintenance-package version.

@Copilot Copilot AI review requested due to automatic review settings May 21, 2025 20:58
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This pull request updates the pruning versions for maintenance packages in the .NET build tasks, ensuring that only frameworks previously pruning the version just before the maintenance-package version are updated.

  • Updated maintenance-package versions for NETStandard2.1, NETCoreApp3.1, NETCoreApp2.1, NET6.0, and NET5.0 frameworks.
  • Bumps include packages such as System.Buffers, System.Memory, System.Numerics.Vectors, System.Reflection.DispatchProxy, among others.

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file
File Description
src/Tasks/Microsoft.NET.Build.Tasks/FrameworkPackages/FrameworkPackages.netstandard2.1.cs Bumped versions for System.Buffers, System.Memory, System.Numerics.Vectors, and System.Threading.Tasks.Extensions.
src/Tasks/Microsoft.NET.Build.Tasks/FrameworkPackages/FrameworkPackages.netcoreapp3.1.cs Updated System.Reflection.DispatchProxy version.
src/Tasks/Microsoft.NET.Build.Tasks/FrameworkPackages/FrameworkPackages.netcoreapp2.1.cs Updated versions for System.Memory, System.Numerics.Vectors, System.Threading.Tasks.Extensions, and System.ValueTuple.
src/Tasks/Microsoft.NET.Build.Tasks/FrameworkPackages/FrameworkPackages.net6.0.cs Raised the version for System.Runtime.CompilerServices.Unsafe.
src/Tasks/Microsoft.NET.Build.Tasks/FrameworkPackages/FrameworkPackages.net5.0.cs Updated System.Reflection.DispatchProxy version.

This updates pruning versions for maintenance-packages.  We do so only on frameworks where they were previously pruning the version just before the maintenance-package version.
@ericstj ericstj force-pushed the addMPVersionsToFrameworkPackages branch from e968482 to 380b99b Compare May 21, 2025 21:01
@@ -17,23 +17,23 @@ internal static class NETCoreApp21
{ "Microsoft.NETCore.App", "2.1.0" },
{ "Microsoft.VisualBasic", "10.3.0" },
{ "Microsoft.Win32.Registry", "4.5.0" },
{ "System.Buffers", "4.5.0" },
{ "System.Buffers", "4.6.1" },
Copy link
Member Author

@ericstj ericstj May 21, 2025

Choose a reason for hiding this comment

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

We cannot change

because netcoreapp2.0 only included assembly 4.0.2.0 while the package has 4.0.3.0.

{ "System.Memory", "4.5.5" },
{ "System.Numerics.Vectors", "4.5.0" },
{ "System.Memory", "4.6.3" },
{ "System.Numerics.Vectors", "4.6.1" },
Copy link
Member Author

Choose a reason for hiding this comment

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

We cannot change

because netcoreapp2.0 only included assembly 4.1.3.0 while the package has 4.1.4.0.

@@ -19,7 +19,7 @@ internal static class NETCoreApp31
{ "System.ComponentModel.Annotations", "4.7.0" },
{ "System.Diagnostics.DiagnosticSource", "4.7.0" },
{ "System.IO.FileSystem.AccessControl", "4.7.0" },
{ "System.Reflection.DispatchProxy", "4.7.0" },
{ "System.Reflection.DispatchProxy", "4.8.2" },
Copy link
Member Author

Choose a reason for hiding this comment

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

We cannot change




Because of the following versions in framework, while the package uses 4.0.6.0:

Framework Version in Framework
netcoreapp2.0 4.0.3.0
netcoreapp2.1 4.0.4.0
netcoreapp3.1 4.0.5.0
netstandard2.1 4.0.5.0

@@ -18,7 +18,7 @@ internal static class NETCoreApp60
{ "System.Formats.Asn1", "6.0.0" },
{ "System.Net.Http.Json", "6.0.0" },
{ "System.Reflection.Metadata", "6.0.0" },
{ "System.Runtime.CompilerServices.Unsafe", "6.0.0" },
{ "System.Runtime.CompilerServices.Unsafe", "6.1.2" },
Copy link
Member Author

Choose a reason for hiding this comment

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

We can't change past versions for this, of course, because it was still shipping major versions/API.

{ "System.Reflection.DispatchProxy", "4.5.0" },
{ "System.Reflection.Metadata", "1.6.0" },
{ "System.Security.AccessControl", "4.5.0" },
{ "System.Security.Cryptography.Cng", "4.5.2" },
{ "System.Security.Cryptography.OpenSsl", "4.5.0" },
{ "System.Security.Principal.Windows", "4.5.0" },
{ "System.Threading.Tasks.Dataflow", "4.9.0" },
{ "System.Threading.Tasks.Extensions", "4.5.4" },
{ "System.ValueTuple", "4.5.0" },
{ "System.Threading.Tasks.Extensions", "4.6.3" },
Copy link
Member Author

Choose a reason for hiding this comment

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

We cannot change

because netcoreapp2.0 only included assembly 4.1.1.0 while the package has 4.2.1.0

Versions 4.4.0 and later for this package all have a placeholder for
`netstandard2.0` so it's safe to prune as it doesn't expose any
reference.
@ericstj ericstj requested review from dsplaisted and ViktorHofer May 21, 2025 21:26
Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

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

"System.Runtime.CompilerServices.Unsafe", "6.1.2"

This means that we would need to update this data every time m-p publishes new packages, right? For PackageOverrides.txt entries we chose the next major version: https://github.com/dotnet/runtime/blob/e163124bce28b7e868b62f4efd498fcaa7f95301/src/installer/pkg/sfx/Microsoft.NETCore.App/PackageOverrides.txt#L225

Can we do the same here? In general it would be good use the same versions as in PackageOverrides.txt for these m-p packages.

@ericstj
Copy link
Member Author

ericstj commented May 28, 2025

"System.Runtime.CompilerServices.Unsafe", "6.1.2"

This means that we would need to update this data every time m-p publishes new packages, right? For PackageOverrides.txt entries we chose the next major version: https://github.com/dotnet/runtime/blob/e163124bce28b7e868b62f4efd498fcaa7f95301/src/installer/pkg/sfx/Microsoft.NETCore.App/PackageOverrides.txt#L225

Can we do the same here? In general it would be good use the same versions as in PackageOverrides.txt for these m-p packages.

I think @dsplaisted already employ's lifting of these package versions

if (key.TargetFrameworkIdentifier.Equals(".NETCoreApp", StringComparison.OrdinalIgnoreCase) && !p.Value.IsPrerelease)
{
// If a given version of a package is included in a framework, assume that any patches
// to that package will be included in patches to the framework, and thus should be pruned.
// See https://github.com/dotnet/sdk/issues/44566
// To do this, we set the patch version for the package to be pruned to 32767, which should be
// higher than any actual patch version.
var maxPatch = new NuGetVersion(p.Value.Major, p.Value.Minor, 32767);
version = maxPatch.ToString();
}

@ericstj ericstj requested a review from ViktorHofer May 28, 2025 15:48
@ViktorHofer
Copy link
Member

If I read the code correctly, only if the package uses a prerelease version. The m-p ones use a stable version.

@ericstj
Copy link
Member Author

ericstj commented May 28, 2025

If I read the code correctly, only if the package uses a prerelease version. The m-p ones use a stable version.

No - it's for non-prerelease. It's disabled for pre-release where API and features of the package might be changing more often. Once the package is released we're in "servicing" in which case this rule to prune higher patch versions is applied.

@ViktorHofer
Copy link
Member

Sounds good. Should conflict resolution get updated to use the same algorithm?

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update pruned package data for packages that ship out of dotnet/maintenance-packages
2 participants