-
Notifications
You must be signed in to change notification settings - Fork 644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SemVer 2.0 - improve messaging for SemVer 2.0 upload and packages page #4215
Comments
Provided the scenarios we should warn for and the error messages. |
I do want to point out that none of the server APIs are considering the package to be SemVer 2.0.0 in Case 3. These packages are not considered to be SemVer 2.0.0 and e.g. NOT HIDDEN on V2 OData endpoints, as all we check is the package's nuspec manifest. This is one of the edge cases described in the non-goals (paragraph 2) that may lead to (gracefully handled) restore failures on non-SemVer2 compatible clients. |
@xavierdecoster: What does 'gracefully handled' mean? Also if the publisher releases a newer non SemVer 2 version of the package, then the restore would continue with warning. Right? |
Gracefully handled indeed means: it won't crash, and be treated as a package not found causing restore failure. Once a newer non SemVer2 version of the dependency is made available, restore will just work (given the newer version does not violate the upper-bound of the dependency version range of course). |
Pending documentation the message link points to: https://github.com/NuGet/docs.microsoft.com-nuget/issues/376 |
Exact messages will be provided by @anangaur
Edit: Proving the details:
Problem
SemVer 2.0 packages will not be visible from legacy clients (i.e clients before NuGet 4.3 release). In order to make sure that publishers are aware that they are about to publish a SemVer 2 package, they should be warned appropriately so that this is a conscious decision and not an inadvertent one.
Read more on Identifying SemVer v2.0.0 Packages
One of the concerns is that a build metadata (e.g. 2.1.0**+buildmetadata**) also constitutes a Semver 2 version though this build metadata does not form the identity of the package.
Solution
The idea here is to warn enough at the client (NuGet/Home#5493) and on the NuGet.org server (this issue) when there is an intent or when the package is published.
Following is the list of cases and NuGet should identify to determine a SemVer 2 package and corresponding warning messages NuGet should output:
Case 1: Package has prerelease SemVer 2 versioning
Warning1:
Title: This package has a SemVer2 package version
Message: This package will only be available to download with SemVer2 compatible NuGet clients, such as Visual Studio 2017 (version 15.3) and above or NuGet client 4.3 and above. Read more
Case 2: Package has a non-semver2 version, but is considered semver2 due to a dependency declaration
Warning2
Title: This package is considered a SemVer2 package as it has dependency on SemVer2 package(s)
Message: This package will only be available to download with SemVer2 compatible NuGet clients, such as Visual Studio 2017 (version 15.3) and above or NuGet client 4.3 and above. Read more
Case 3: Package has dependecy declared as SemVer 1 but the available dependency matching default dependency resolution Lowest itself is SemVer 2 (due to build metadata)
Warning2 as described above.
NuGet Server should warn for the above scenarios during:
The text was updated successfully, but these errors were encountered: