[DCR]: Allow floating versions with Central Package Management (CPM)

[BamButz]

Details about Problem

We use CPVM to manage our dependencies. Unfortunately, the last update presented us with a big problem. With the introduction of NU1011, it is no longer possible for us to run a resolution strategy that selects the highest possible version. This is especially relevant for our in-house dependencies, as we distribute regular patches and this can no longer be done automatically.

Suggested things

Our suggestion is to implement a switch that deactivates the validation of NU1011. We understood the problem that led to the implementation of NU1011, but can rule out the problem for us.

[aortiz-msft]

Thank you for your feedback! We are evaluating all the feedback provided for the preview release of CPVM to understand how we can improve the design for its final release in an upcoming version of .NET.

[glennawatson]

This is a common problem for projects I'm involved in as well.

Seems to issue is coming from https://github.com/NuGet/NuGet.Client/blob/729776540d77de5c476e24a61ebcadc37002df21/src/NuGet.Core/NuGet.Commands/RestoreCommand/RestoreCommand.cs#L494

[voroninp]

@BamButz ,

We understood the problem that led to the implementation of NU1011,

Could you explain, please?
I'm still scratching my head in attempts to understand why this limitation was introduced.

[BamButz]

I'm afraid I'm not really into the topic anymore, but you can read up on this issue.

[elpht]

Won't this be a candidate for next Central Package Management improvements epics?

[handerss-spotfire]

This feature would be great, it would allow us to switch from the MSBuild version of central package versions which does support this.

[ds1709]

We are using SonarAnalyzer.CSharp in our projects. To be sure we are using the latest version, in package reference version is 8.*. Becase floating versions are not supported, we cant move to CPMV yet.

[jeffkl]

We have updated the documentation to explain more about the decision to not have CPM support floating versions.

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

[handerss-spotfire]

@jeffkl An example of a "enterprise-level" use-case for floating versions is internally published NuGet packages. In our use-case for example we publish internal packages with semantic version numbers which match across different projects and then bump the prerelease tag, or the 4th number in the version. The prerelease tag can also be made to match specific branch identifiers. This means we publish new versions of internal packages dozens of times per day (for a larger enterprise this could of course be hundreds of times per day). Having a commit for each such bump would make the commit log very noisy.

Perhaps floating package versions could be added with a more explicit way of opting in? E.g. via a flag in the csproj (this way it would be easy to disallow floating versions for builds being built in release configurations).

[jeffkl]

@handerss-tibco that's an interesting example. Does your organization ever experience issues with that set up? For example, does a bad package get pushed and it breaks everything because everyone downstream automatically consumes it? It seems really risky and non-deterministic, especially since NuGet has an HTTP cache. There is no example that a package that was just pushed will be consumed (unless you're clearing the HTTP cache constantly). Do you ever find that different machines end up with different versions of dependencies?

Perhaps floating package versions could be added with a more explicit way of opting in?

I'm definitely considering this possibility. I'm still trying to determine if it sets people up for success. One of the things I worry about is your organization hires a new employee. That person's interaction with NuGet might be rocky based on your work process and they might blame NuGet as a product for the constant breakage and non-determinism when its not a recommended scenario.

[glennawatson]

@jeffkl this scenario also comes up a bit on the reactiveui open source project. We have internal packages we push we rely on from other repo we just want to rely on latest.

[jeffkl]

@glennawatson okay thanks for chiming in. Are you okay with the fact that based on NuGet's HTTP cache, there's no guarantee that any give machine is actually using the "latest"? And that if any of the packages are bad, you have to push a fixed package and wait for the HTTP cache to expire/manually clear it before things are working again? Essentially, are you okay with such non-determinism and no ability to roll back to a known good state?

[glennawatson]

In this scenario yes.

[handerss-spotfire]

@jeffkl It seems we're indeed clearing the HTTP cache for package listings which use floating versions, which I don't think is ideal. In our scenario it would be preferred if there was a guarantee that the latest package is used, however I realize that cannot be achieved without negatively affecting build times.

A better solution would be if there was a CLI command which performs this style of update. I believe this is achieved in npm for example via npm-update which updates according to constraints specified in package.json (similar to Directory.Packages.props). In other package managers this can usually be achieved by removing the lock file.

[jeffkl]

I'm going to explore adding a feature flag to enable floating versions in central package management which the user would have to opt into. There are some concerns that it would be wholly incompatible with transitive pinning which I'll look into.

[bkoelman]

The lack of floating version support in CPM is an adoption blocker for my project as well, and the guidance to use dependabot instead isn't an option.

My team builds a public NuGet package that depends on EF Core. In the project file, we have pinned the Microsoft.EntityFrameworkCore dependency to a specific version, which we can only update in the next major release. But at the same time, we want to run our test suite against the latest patch version, so we'll know when something breaks. Therefore we need to use a floating version of Microsoft.EntityFrameworkCore in tests. If supported, we'd define the floating version in Directory.Packages.props (for tests, benchmarks, examples), then use VersionOverride in the library project to pin.

Dependabot is unable to deal with this. It's only possible to exclude a package globally, not per project. So we had to exclude Microsoft.EntityFrameworkCore from scanning.

The package caching is not a concern for us, because our GitHub Actions runners that verify the build quality always start clean.

[jeffkl]

Just an FYI to everyone involved in this issue, we'll be adding an option to enable floating versions for CPM in the next release. It will still be off by default but a user can enable it going forward. NuGet/NuGet.Client#5440

[jeffkl]

Reopening as this was reverted, I am working on making it pass our insertion criteria

[JeffYoungHRB]

This is preventing our adoption as well.
Many of our internal packages contain things like an enumeration that we add to and want every consumer of the package to get the latest on build. The only way I can see doing that without a flag is adding to the ado build pipeline to unlist the prior versions.