Why does nuget consider 1.2.3.4 to be a stable (release) version?

1
votes

I'm seeing below:

1.2.3          // release
1.2.3+hash     // release
1.2.3-alpha    // pre-release
1.2.3-alpha.12 // pre-release

1.2.3.4        // why is this release version and not pre-release version or invalid?
1.2.3.4.5      // invalid nuget version

I don't see why 1.2.3.4 is considered as a release version mentioned anywhere below:

1
nugetnuget-packagesemantic-versioning
The short answer is that Microsoft wanted to adopt SemVer while at the same time maintaining backward compatibility with their 4-part versioning scheme, where even release versions can have 4 parts. – Joe Sewell

1 Answers

2
votes

What is the definition of a pre-release version?

NuGet (mostly) conforms to SemVer2, as defined on their website: https://semver.org/

Section 9 starts: https://semver.org/#spec-item-9

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version

But SemVer2 doesn't allow 4 segment versions

Correct, but as Joe Sewell mentioned in the question's comment, NuGet was adding backwards compatibility support for what it previously supported. In fact, here's the commit that added SemVer support into NuGet, back in 2011: https://github.com/NuGet/NuGet2/commit/a999416414071f321f1ad5aa6d8c744ba0715e3a

We can see from numerous files that NuGet was previously using System.Version as the package version before this, and you can see from System.Version's docs that it contains this 4 segment version. The very first version of SemVer.cs contained the comment:

A hybrid implementation of SemVer that supports semantic versioning as described at http://semver.org while not strictly enforcing it to allow older 4-digit versioning schemes to continue working.

The file was later renamed to SemanticVersion, and later split into a NuGetVersion, extending a strictly-semver2 SemanticVersion, but this comment still exists to this day.

Conclusion

So, while SemVer2's definition of pre-release explicitly requires the hyphen to immediately follow the patch version, backwards compatibility prevented NuGet, even as young as 1 year after initial release, from moving exclusively to strict SemVer2 compliance.

Therefore, some reinterpretation of SemVer2 was needed, and the choice was to make the hyphen the pre-release signal, not having more than 3 segments. 9 years later this is what we have, and there are thousands of packages on nuget.org using 4 segment versions, some with additional prerelease labels.