-
Notifications
You must be signed in to change notification settings - Fork 527
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
Version scheme to use in Paket #289
Comments
I vote for semver 2 + "accepting nuget versions" even if we order
|
+1 for @forki 's suggestion |
Sounds good! AlexAlexander Groß On Thu, Oct 23, 2014 at 10:54 AM, Daniel Nauck notifications@github.com
|
@forki What do you mean by "accepting nuget versions", can you elaborate more on it? |
It's more a hint to the future. I think we should understand nuget
|
I wonder what NuGet will do w.r.t. backward compatibility. Not all packages will immediately update their versions, some. nuget v3-powered projects will still have to rely on semver v1 packages. So, I feel we should support both. Can we detect whether the prerelease version is SemVer v1 or v2? I think we can assume that all preleases for a version use a single format. But perhaps I got something wrong. In this case, please enlighten me :-) |
The difference between the two is mostly in pre-release identifiers: An identifier can only consist of ASCII numerics plus dash
If all major, minor and patch versions are the same, the pre-release version is used to determine precedence:
v2 also has a notion of build metadata, denoted by a Based on this, if the version contains a For reference, see the BNF grammar. |
The difference is in the pre-release identifiers and notion of build metadata, as @khellang already mentioned. According to v2 spec
Further according to provided BNF grammar identifiers like Basically v1 pre-release identifiers would be parsed as one part v2 identifiers. Except the cases where the identifier would be invalid in v2, like mentioned earlier @agross As NuGet only sorts in lexographic ASCII order the only difference in sorting would result when v2 would detect numeric identifiers, as they have lower precedence that alphanumeric ones and would be sorted numerically in their category. This newly detected numeric identifiers would break the order produced by previous NuGet versions. I don't know how strict we want to follow SemVer spec. I understand that with strict implementation we could have problems with some package versions, but for now I would go for this conflict. Maybe it's not that often in the wild. Regarding legacy build number part of NuGet packages, we could interpret them as first pre-release identifier as they take precedence in NuGet's version sorting over SemVer pre-release identifiers and are sorted numerically. Further |
While working on a fix for #263 I've looked inside the SemVer spec, NuGet docs and code.
The current NuGet version supports SemVer 1.0.0 spec.
Additionally it allows the legacy versions with 4 numeric parts.
The current developed NuGet version (3.x) will support the SemVer v2.0.0 spec. Blog post
Paket currently goes for support of SemVer v1 with the extension for a build part, like NuGet >= v1.6.
If I got it correctly, we don't want to simply copy NuGet's behavior.
With it I mean we have to decide which version scheme we want to follow and fully support.
I want to underline that correctly supporting SemVer 1.0.0 and 2.0.0 side-by-side will be very difficult, as the specs defines different strategies for handling i.e. sorting of pre-release versions.
I understand the wish to make the transition to Paket as simple as possible, but I would suggest to be very strict at the point of versioning.
We could provide a possibility for the user to define the version scheme to use or simply go for SemVer v2?
Note
When NuGet v3 gets released we would need to support SemVer v2 anyway and handle different NuGet versions in
convert-from-nuget
process correctly.The text was updated successfully, but these errors were encountered: