Compatibility regarding hyphens with npm version parsing about semver HOT 8 CLOSED

Hmmm, I believe those are in violation of the Semver spec. I'll have to re-read it to be sure.

On Nov 25, 2015, 19:50 -0500, Robin [email protected], wrote:

Someweirderexamples which are parsed successfully with npm but not with this library:

failed to parse version of cordova, version: 3.0.0-rc1-1 failed to parse version of npm, version: 1.5.0-alpha-0 failed to parse version of karma, version: 0.12.11-beta-3029418

—
Reply to this email directly orview it on GitHub(#64).

from semver.

Yes, with two hyphens, doesn't work:

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

Those second -s should be .s.

I wonder what the current level of compatibility is between languages.

@indirect, @izs / @ashleygwilliams, and maybe... @dstufft ? I'm not sure how it works in Python land.

Has there been any kind of discussion on Ruby/JavaScript/Python Semver parsing compatibility? It might be nice to compare implementations. Maybe some sort of common test suite?

from semver.

Python packaging does not use semver, we have our own standard that deals with legacy of a decade worth of laissez faire version numbers. Our standard is relaxed enough though and we kept semver in mind so that it's possible to use most of semver (but not everything, a few edge-ish things aren't supported) and still be successfully parsed by our standard.

from semver.

Thanks Donald, I thought I remembered things being a bit different. I guess there'd be less value for trying to work together there.

from semver.

We also have decades of weird legacy version numbers, but we have been consistent the entire time about letters [a-zA-Z] in the version number meaning it's a prerelease. I don't think gems are ever allowed to have dashes in their versions.

from semver.

According to the SemVer spec 2.0, section 9 (emphasis added):

9 A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].

So, 1.2.3-- is allowed. It has a single prerelease identifier of -. It seems to me that this is a bug in this library. Luckily, it is a bug in the easy direction; fixing it will not cause the library to stop allowing something that was previously allowed :)

Numeric prerelease identifiers are lower precedence than alphanumeric identifiers. So, 1.0.0-alpha.0 is lower precedence than 1.0.0-alpha.beta. Thus, the lowest possible precedence SemVer would be 0.0.0-0

It is unclear (to me at least) whether an empty set of prerelease identifiers is allowed, or what its precedence would be. node-semver handles this by treating 0.0.0- as an error in strict mode, and as a prerelease of - in loose mode.

Node-semver's strict mode should be an unambiguous implementation of SemVer 2. Node-semver's loose mode, however, reflects the fact that we also have a fair bit of legacy in our versions. npm was initially developed back when SemVer was just beginning to rise in prominence, before it even had a 1.0 specification yet.

Today, most implementations should be relatively consistent with the SemVer 2 spec. If version numbers sent to npm are valid in SemVer 1, but not valid SemVer 2, then they are coerced into a valid SemVer 2 form with the same semantics.

At this time, there hasn't been much work done to specify version range identifiers across platforms. Node-semver's ranges have a bnf grammar, and the behavior is documented in detail, if you care to copy how they work. The only deviation from node-semver's range definition and implementation is that it allows ranges like 2.x.4 which is interpreted as equivalent to 2.x, but should ideally be an error, because it doesn't make much sense. (I only want the 4th patch of any 2.x? Why? That's weird.)

from semver.

But, back to @steveklabnik's suggestion, yes, those -'s should ideally be .'s instead. Why? Because 1.2.3-a-2 > 1.2.3-a-10 but 1.2.3-a.2 < 1.2.3-a.10, because the . separates the identifiers so that numeric identifiers can be compared numerically.

from semver.

Yeah I agree with the points mentioned, but I'd prefer handling the versions somehow even if the result is not perfect, but these sadly are real world examples that error out at the moment.

from semver.