Update maintenance-packages pruning versions

[ericstj]

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]

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.

[ViktorHofer]

"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]

"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

sdk/src/Tasks/Microsoft.NET.Build.Tasks/GetPackagesToPrune.cs

Lines 214 to 223 in 2310f2b

	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();
	}

[ViktorHofer]

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

[ericstj]

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]

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

[ericstj]

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

No I don't think so. Conflict resolution doesn't need to approximate. It also knows nothing about frameworks today. It's much more general purpose.

The reason we do this for pruning is because we have a specific opinion/policy about the packages that overlap with .NETCore.

[ericstj]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ViktorHofer]

Thanks for your patience when addressing my questions. Last one:

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.

So every time we bump the major/minor version of these m-p packages, we would need to update these versions here. Do we expect more minor version m-p updates going forward? If so, would it be better to use a high minor and patch version instead? I.e. 6.99.99.

[ericstj]

We expect no minor version updates from maintenance-packages.

[ericstj]

I'll add to this that it's really just a convenience. Most of these packages now use placeholders for frameworks where they are dropped, and most of their dependencies from newer versions are up to date, so removing them just saves on download - not false positives or large unused package graphs.

[ericstj]

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

No I don't think so. Conflict resolution doesn't need to approximate. It also knows nothing about frameworks today. It's much more general purpose.

The reason we do this for pruning is because we have a specific opinion/policy about the packages that overlap with .NETCore.

Thinking more about this, I think we had previously suggested this just for PackageOverrides.txt, so I'll file an issue for @dsplaisted to follow up.

[ericstj]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[ericstj]

/ba-g all test failures are known