Warning when version range upper version does not end in `-0`

[zivkan]

NuGet Product(s) Involved

NuGet.exe, MSBuild.exe, dotnet.exe

The Elevator Pitch

According to SemVer2, 1.0.0 < 2.0.0-alpha < 2.0.0. But customers frequently use range [1.2.3, 2.0.0) hoping to limit the range to 1.x, but this doesn't take into account pre-release versions.

Therefore, I propose a warning when:

• it finds a package where an upper version is specified
• the upper version is not inclusive () rather than ])
• the upper version does not have a prerelease label, then a warning is shown.

Something similar to:

Warning NUxxxx: Package Contoso.Utilities requests versions [1.2.3, 2.0.0) but will match pre-release version such as 2.0.0-alpha. To exclude prerelease versions, change the version range to [1.2.3, 2.0.0-0)

I'm not sure if this should only be a pack warning (dependency version), only be a restore warning (PackageReference version), or both.

Additional Context and Details

Consider issues like:

• NU1608 warning is not evaluating prerelease versions combined with exclusive upper bounds properly #6434
• [Bug]: VersionRange [1.0.0, 2.0.0) matches version 2.0.0-alpha.1 which can break package graphs #12082

I agree that the behaviour is non-intuitive, and that many customers would prefer the version range comparison to exclude the pre-release versions instead, but it's a breaking change whose magnitude of impact is unknown. This proposal could help package authors in particular minimize risk that their packages claim compatibility with pre-release packages.

[DavidBoike]

This warning seems like it would generate a ton of confusion amongst the thousands of developers that would have no idea what was going on. Maybe fixing #6434 would actually be more straightforward. 😉

[zivkan]

Is the proposed warning message not sufficiently clear? I know that working on NuGet I know the SemVer spec better than the average developer, but I tried to make the message clear enough to reduce confusion, not add to it.

[ramonsmits]

That would be super strange. Don't forget that now suddenly you see such version range on Nuget.org listed everywhere.

This change doesn't make sense IMHO. Also don't forget there are thousands of packages without the -0 workaround that expect that behavior to not match prereleases for the right / max side of the range.

This change wouldn't fix any of these already created packages. Fixing the version matching would actually fix incorrect behavior for all those thousands of packages without needed to push a new "patch" release.

[DavidBoike]

Is the proposed warning message not sufficiently clear? I know that working on NuGet I know the SemVer spec better than the average developer, but I tried to make the message clear enough to reduce confusion, not add to it.

No, I was being sarcastic. Sorry about that. I'm saying the warning should not exist, because imagine what all those developers who think they know how NuGet works start getting this warning telling them they need to do this odd workaround that only must exist because nobody will fix #6434. As much discussion in that issue is complaining about how fixing it would be a breaking change, it seems like that big breaking change would probably be less problematic than a warning like this.

I like this issue from the angle of "If you're not going to fix it, then you really should do this instead" to illustrate that the "breaking change" is the better course of action.

But it's worth pointing out that in #6434 there's plenty of evidence that the -0 suffix doesn't really work appropriately either.

[zivkan]

I missed the comment that said NU5104 was being raised when an exclusive upper bound uses -0. I think that's a bug in the pack warning, so I created this issue:

• NU5104 (stable package should not use prerelease) should not warn when upper version uses -0 #12424

[nkolev92]

When a range is specified with either a lower or upper boundary of prerelease it opts in the package into prerelease versions, so I'm not certain it's the right behavior. By specifying a stable range only, you'll only get prerelease versions if another component in the graph asks for a prerelease version of the package.

When only stable versions are specified by the project or dependencies, then only stable versions will be considered. That is how the https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1103 warnings comes to be, which warns about not finding a matching stable version of a package while a prerelease is available.

NuGet will not choose a prerelease version for a specific package unless someone asks for a prerelease versions which adding an upper range with a prerelease effectively does.