[GH-ISSUE #324] Are negative pre-release and build metadata integers allowed? #4479

Closed
opened 2026-06-13 12:35:04 -05:00 by GiteaMirror · 6 comments
Owner

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

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
Author
Owner

@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.

<!-- gh-comment-id:231748277 --> @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.
Author
Owner

@FichteFoll commented on GitHub (Jul 11, 2016):

None of these should cause a parsing error (besides the v prefix, 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.

<!-- gh-comment-id:231760471 --> @FichteFoll commented on GitHub (Jul 11, 2016): None of these should cause a parsing error (besides the `v` prefix, 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.
Author
Owner

@haacked commented on GitHub (Jul 11, 2016):

would "-45" be a numeric or alphanumeric identifier?

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):

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. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

I think the intent is pretty clear, but the language is a bit ambiguous and could probably be made more explicit.

<!-- gh-comment-id:231815125 --> @haacked commented on GitHub (Jul 11, 2016): > would "-45" be a numeric or alphanumeric identifier? 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): > 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. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. I think the intent is pretty clear, but the language is a bit ambiguous and could probably be made more explicit.
Author
Owner

@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).

identifiers with letters or hyphens are compared lexically in ASCII sort order

Reference

<!-- gh-comment-id:231857172 --> @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). > identifiers with letters or **hyphens** are compared lexically in ASCII sort order [Reference](http://semver.org/#spec-item-11)
Author
Owner

@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!

<!-- gh-comment-id:231866988 --> @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!
Author
Owner

@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.

<!-- gh-comment-id:1830381924 --> @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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#4479