Option in CPM to use 'newest available' floating version resolution (highestMinor or highestPatch) instead of oldest available

[Grastveit]

We are requesting a configuration option within Central Package Management (CPM) to change the default behavior of floating version resolution from oldest available to newest available (highest patch or highest minor version).

Scenario

We use floating versions for our internal NuGet packages (e.g., Version="1.0.*"). This approach is by design, allowing developers to automatically pick up the latest updates in a standard build flow.
We recently attempted to migrate our version management to Central Package Management (Directory.Packages.props) to DRY our configurations.

Problem

We discovered that when using CPM, the dotnet restore --force-evaluate command resolves to the oldest available version that matches the float pattern, whereas specifying versions directly in .csproj files resolves to the newest available version.
This difference in behavior prevents us from migrating to CPM, as we rely on the newest available version resolution to ensure developers are always building against the most current internal package updates.

Desired Behavior

We would like a configuration property (e.g., in Directory.Packages.props) that allows users to explicitly opt-in to the newest available resolution strategy when using floating versions within CPM.
Example properties could be <CentralPackageFloatingVersionResolution>Newest</CentralPackageFloatingVersionResolution> or a similar mechanism that aligns the CPM behavior with the behavior previously found in non-CPM projects.

[marcpopMSFT]

CC @jeffkl

[Grastveit]

It case it makes a difference: We currently use "*" as floating version. We are planning to use "1.0.*", as shown in the e.g., so that dependencies between packages we create will be floating instead of specific resolved at package-pack-time.

[dotnet-policy-service]

Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!

If you believe this issue was closed out of error, please comment to let us know.

Happy Coding!

[jeffkl]

I believe this is already possible, you can specify a floating version but you'll get an error which you can disable.

https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1011

I would of course never recommend it.

<PropertyGroup>
  <CentralPackageFloatingVersionsEnabled>true</CentralPackageFloatingVersionsEnabled>
</PropertyGroup>