mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #324] Are negative pre-release and build metadata integers allowed? #4479
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @johnrs on GitHub (Jul 10, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/324
I see that negative major, minor, and patch integers are not allowed. Does this restriction also apply to pre-release and build metadata integers? For example, in "v1.2.3-beta.-45" or in "v1.2.3--45" would "-45" be a numeric or alphanumeric identifier?
Thanks, John
@crazedsanity commented on GitHub (Jul 11, 2016):
It seems to me that having negative numbers would lead to parsing errors. And confusion.
Explaining the motivation for your question, or for the implied want to allow them, may help stimulate the conversation.
@FichteFoll commented on GitHub (Jul 11, 2016):
None of these should cause a parsing error (besides the
vprefix, which is not part of a semver) since hyphens are allowed in both pre-release and metadata identifiers.What remains unclear is whether numeric characters prefixed with a hyphen should be treated as negative numeric identifiers. The spec itself only mentions that numeric identifiers must not have leading zeros.
@haacked commented on GitHub (Jul 11, 2016):
I'd argue that it would not be a numeric identifier. Alphanumeric refers to
[a-zA-Z0-9]so the assumption is numeric is the[0-9]portion of the alphanumeric.Also, when thinking of a numeric identifier, we can look at previous examples (Major, Minor, Patch) to get a sense of the intent. Here's a snippet, (emphasis mine):
I think the intent is pretty clear, but the language is a bit ambiguous and could probably be made more explicit.
@JacksonBailey commented on GitHub (Jul 11, 2016):
Let's get one thing clear, if they are allowed to be present and how they are sorted are two different questions. For both types of identifiers, pre-release and build metadata, yes they are allowed (assuming they take from the character set
[0-9-]).As for sorting, build metadata does not have a specified way to be sort.
A negative number in pre-release identifiers would be considered text for sorting. See below a portion of item 11 from the spec (emphasis mine).
Reference
@johnrs commented on GitHub (Jul 11, 2016):
Thanks for all the info. Upon reading the spec again, it does seem that anything with a hyphen is considered an alphanumeric ID, not numeric. Why is this important? Sort order. I'm assuming that numeric ID fields should be sorted in number order as they are in Major/Minor/Patch fields.
I agree that the intent seems clear, but that the language could be more explicit, including both the negative and the sorting aspects for ID's.
Thanks!
@sometimesacoder commented on GitHub (Nov 28, 2023):
I think the language needs to be more explicit as well. The "Backus–Naur Form Grammar for Valid SemVer Versions" clearly states that "numeric identifier" is a "positive digit". The text of section 9 says "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version", and "Numeric identifiers MUST NOT include leading zeroes". So we know for sure that pre-release contains identifiers and contains numeric identifiers, and the Backus-Naur form grammar tells us numeric identifiers cannot be negative, but we only know this from the Backus-Naur form grammar, the text itself is ambiguous on whether a number can be negative or not in a pre-release.
For the version pieces the text is explicit, "A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes.", I feel like this same explicit language needs to be in the pre-release definition as well since it is very important for getting sort order correct because text has higher precedence than numbers according to the spec, but lexical/ascii order puts the dash before numbers, so the sort order is different when one parses "-1" as a number instead of as text: the proper order is "-1" is earlier/less than "-2" when reading this as text, but when parsed as numbers -2 is less than than -1.