Is an invalid numeric identifier in the prerelease section to be treated as an alphanumeric identifier #410

New Issue

GiteaMirror · 2026-02-17T12:02:31-06:00

GiteaMirror commented

2026-02-17 12:02:31 -06:00

Originally created by @Nemo157 on GitHub (Apr 27, 2020).

Specifically, for this version number:

1.0.0-alpha.01

Is this an invalid version, or should it be parsed as

{
  major: 1,
  minor: 0,
  patch: 0,
  prerelease: [Alphanumeric("alpha"), Alphanumeric("01")]
}

From my reading of ¶11 "identifiers consisting of only digits are compared numerically" is the closest thing to a definition of what a "numeric identifier" is, and according to ¶9 "Numeric identifiers MUST NOT include leading zeroes". I could see an alternative reading that any potentially valid prerelease identifier that is invalid as a numeric identifier should instead be treated as an alphanumeric identifier (which matches the grammar given, but nowhere does it say whether this grammar is meant to be normative or not).

Originally created by @Nemo157 on GitHub (Apr 27, 2020). Specifically, for this version number: ``` 1.0.0-alpha.01 ``` Is this an invalid version, or should it be parsed as ``` { major: 1, minor: 0, patch: 0, prerelease: [Alphanumeric("alpha"), Alphanumeric("01")] } ``` From my reading of ¶11 "identifiers consisting of only digits are compared numerically" is the closest thing to a definition of what a "_numeric identifier_" is, and according to ¶9 "Numeric identifiers MUST NOT include leading zeroes". I could see an alternative reading that any potentially valid prerelease identifier that is invalid as a numeric identifier should instead be treated as an alphanumeric identifier (which matches the grammar given, but nowhere does it say whether this grammar is meant to be normative or not).

GiteaMirror closed this issue

2026-02-17 12:02:32 -06:00

GiteaMirror commented

2026-02-17 12:02:33 -06:00

@Gods465 commented on GitHub (May 1, 2020):

Specifically, for this version number:
1.0.0-alpha.01
Is this an invalid version, or should it be parsed as
{
  major: 1,
  minor: 0,
  patch: 0,
  prerelease: [Alphanumeric("alpha"), Alphanumeric("01")]
}
From my reading of ¶11 "identifiers consisting of only digits are compared numerically" is the closest thing to a definition of what a "numeric identifier" is, and according to ¶9 "Numeric identifiers MUST NOT include leading zeroes". I could see an alternative reading that any potentially valid prerelease identifier that is invalid as a numeric identifier should instead be treated as an alphanumeric identifier (which matches the grammar given, but nowhere does it say whether this grammar is meant to be normative or not).

@Gods465 commented on GitHub (May 1, 2020): > Specifically, for this version number: > > ``` > 1.0.0-alpha.01 > ``` > > Is this an invalid version, or should it be parsed as > > ``` > { > major: 1, > minor: 0, > patch: 0, > prerelease: [Alphanumeric("alpha"), Alphanumeric("01")] > } > ``` > > From my reading of ¶11 "identifiers consisting of only digits are compared numerically" is the closest thing to a definition of what a "_numeric identifier_" is, and according to ¶9 "Numeric identifiers MUST NOT include leading zeroes". I could see an alternative reading that any potentially valid prerelease identifier that is invalid as a numeric identifier should instead be treated as an alphanumeric identifier (which matches the grammar given, but nowhere does it say whether this grammar is meant to be normative or not).

GiteaMirror commented

2026-02-17 12:02:34 -06:00

@wizzwizz4 commented on GitHub (May 2, 2020):

According to my reading of the BNF, it's invalid. According to the regular expression, it's invalid. (According to me, it should be valid – but it is what it is.)

@wizzwizz4 commented on GitHub (May 2, 2020): According to my reading of the BNF, it's invalid. According to the [regular expression](https://regexr.com/53pnt), it's invalid. (According to me, it _should_ be valid – but it is what it is.)

GiteaMirror commented

2026-02-17 12:02:35 -06:00

@Nemo157 commented on GitHub (May 2, 2020):

Ah, I misread the BNF originally, it does require at least one non-digit in an alphanumeric identifier, so that seems to be relatively clear that it is invalid.

@Nemo157 commented on GitHub (May 2, 2020): Ah, I misread the BNF originally, it does require at least one non-digit in an alphanumeric identifier, so that seems to be relatively clear that it is invalid.

GiteaMirror commented

2026-02-17 12:02:35 -06:00

@jwdonahue commented on GitHub (May 3, 2020):

The spec does define numeric values as consisting entirely of the ASCII characters in [0..9], so if there are no alpha-characters, then it's a numeric field and if it's got a leading zero, it's also an invalid numeric field.

@Nemo157, unless you intend to issue an RFC/PR requesting a change, and you have no further questions, please close this issue at your earliest possible convenience.

I would add that falling back to alpha-numeric on leading zero would be a broken design IMO, because the field would then not sort as expected.

@jwdonahue commented on GitHub (May 3, 2020): The spec does define numeric values as consisting entirely of the ASCII characters in [0..9], so if there are no alpha-characters, then it's a numeric field and if it's got a leading zero, it's also an invalid numeric field. @Nemo157, unless you intend to issue an RFC/PR requesting a change, and you have no further questions, please close this issue at your earliest possible convenience. ----- I would add that falling back to alpha-numeric on leading zero would be a broken design IMO, because the field would then not sort as expected.

GiteaMirror commented

2026-02-17 12:02:36 -06:00

@jadaml commented on GitHub (Sep 5, 2021):

I'm sorry for replying to this closed question (or open it if replying to it opens it) with a long-winded reply, but something doesn't sit quite well for me:

The spec does define numeric values as consisting entirely of the ASCII characters in [0..9], […]

I don't find where numeric values are defined in the specs. I don't assume you mean the BNF as I consider that a supplement of the specs as a different point of view, that repeats the description of the specs, and not a defining part of the specs.

On that note, based on what is written in the specs, I technically read it as follows:

¶9 Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]—this does not rule out identifiers with only digits with leading zeroes;
¶9 Numeric identifiers MUST NOT include leading zeroes—technically does not define numeric identifiers as consisting of only digits, but since numbers consist of digits and the sentence declares "Numeric identifiers", one could conclude, that only the series of digits are considered numeric identifiers which do not have leading zeroes;
¶11.4.1 Identifiers consisting of only digits are compared numerically—does not rule out identifiers consisting only of digits with leading zeroes;
¶11.4.2 Identifiers with letters or hyphens are compared lexically in ASCII sort order—does not rule out identifiers consisting only of digits with leading zeroes;
¶11.4.3 Numeric identifiers always have lower precedence than non-numeric identifiers—again, does not rule out identifiers consisting only of digits with leading zeroes.

The rest of the specification is again just the BNF, which I consider a supplement; or rather an implementation of the specification for another interpretation of the text which should match. Otherwise, why not use only the text or BNF?

By this read, Identifiers that only consist of digits and have leading zeroes, are… actually an unnamed group of valid identifiers, because nothing contradicts of the rules highlighted in my previous point. They are even sorted as by ¶11.4.1. Correct me, if this contradicts something in the text of the specs or generally misinterpreted something.

I can perfectly see, how a "001" value could be confusing if treated as an alphanumeric value. But allowing the identifiers be in the range (and for clarity sake, I borrow from regex/BNF) [0-9A-Za-z] while also considering anything that matches 0[0-9]* invalid—which could have a meaning in numeric and alphanumeric sense—is prone to errors; and the implementers have to generate exceptions or accept this otherwise incorrect string input. Neither of them may be desired. By this, it is reasonable for an implementer to try and fit this input in a semantic version implementation. I'm not even considering 0[0-9]*[A-Za-z-]+[0-9]* as I believe it is well established that it is considered alphanumeric value as per ¶9.

So how is numeric identifiers defined?

@jadaml commented on GitHub (Sep 5, 2021): I'm sorry for replying to this closed question (or open it if replying to it opens it) with a long-winded reply, but something doesn't sit quite well for me: > The spec does define numeric values as consisting entirely of the ASCII characters in [0..9], […] I don't find where numeric values are defined in the specs. I don't assume you mean the BNF as I consider that a supplement of the specs as a different point of view, that repeats the description of the specs, and not a defining part of the specs. On that note, based on what is written in the specs, I technically read it as follows: - ¶9 *Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]*—this does not rule out identifiers with only digits with leading zeroes; - ¶9 *Numeric identifiers MUST NOT include leading zeroes*—technically does not define numeric identifiers as consisting of only digits, but since numbers consist of digits and the sentence declares "*Numeric* identifiers", one could conclude, that only the series of digits are considered numeric identifiers which do not have leading zeroes; - ¶11.4.1 *Identifiers consisting of only digits are compared numerically*—does not rule out identifiers consisting only of digits with leading zeroes; - ¶11.4.2 *Identifiers with letters or hyphens are compared lexically in ASCII sort order*—does not rule out identifiers consisting only of digits with leading zeroes; - ¶11.4.3 *Numeric identifiers always have lower precedence than non-numeric identifiers*—again, does not rule out identifiers consisting only of digits with leading zeroes. The rest of the specification is again just the BNF, which I consider a supplement; or rather an implementation of the specification for another interpretation of the text which should match. Otherwise, why not use only the text *or* BNF? By this read, Identifiers that only consist of digits and have leading zeroes, are… actually an unnamed group of valid identifiers, because nothing contradicts of the rules highlighted in my previous point. They are even sorted as by ¶11.4.1. Correct me, if this contradicts something in the text of the specs or generally misinterpreted something. I can perfectly see, how a "001" value could be confusing if treated as an alphanumeric value. But allowing the identifiers be in the range (and for clarity sake, I borrow from regex/BNF) `[0-9A-Za-z]` while also considering anything that matches `0[0-9]*` invalid—which could have a meaning in numeric and alphanumeric sense—is prone to errors; and the implementers have to generate exceptions or accept this otherwise incorrect string input. Neither of them may be desired. By this, it is reasonable for an implementer to try and fit this input in a semantic version implementation. I'm not even considering `0[0-9]*[A-Za-z-]+[0-9]*` as I believe it is well established that it is considered alphanumeric value as per ¶9. So how is numeric identifiers defined?

GiteaMirror commented

2026-02-17 12:02:37 -06:00

@jwdonahue commented on GitHub (Sep 5, 2021):

No single clause in the spec can possibly rule in or out everything. It is the sum of all the statements that comprise the spec. A field containing only the ASCII code points for 0..9, is a numeric field that must not have leading zeros, as defined in clauses 2 and 9. The BNF is a more concise rendering of the spec that reflects the consensus interpretation thereof. A field 001 in the core version triple, or a prerelease tag , is not compliant with the SemVer specification.

@jwdonahue commented on GitHub (Sep 5, 2021): No single clause in the spec can possibly rule in or out everything. It is the sum of all the statements that comprise the spec. A field containing only the ASCII code points for `0..9`, is a numeric field that must not have leading zeros, as defined in clauses [2](https://semver.org/#spec-item-2) and [9](https://semver.org/#spec-item-9). The BNF is a more concise rendering of the spec that reflects the **_consensus interpretation_** thereof. A field `001` in the core version triple, or a prerelease tag , is not compliant with the SemVer specification.

GiteaMirror commented

2026-02-17 12:02:37 -06:00

@jadaml commented on GitHub (Sep 5, 2021):

No single clause in the spec cant possibly rule in or out everything. […]

That is understandable. Luckily I'm not asking of a single clause to rule in or out everything, just want to understand which one or more clauses together rule out 001 as pre-release identifiers.

[…] A field containing only the ASCII code points for 0..9, is a numeric field that must not have leading zeros, […]

Since clause 9 defines pre-release identifiers with two meaning, this statement is insufficient in itself. See reasoning below.

[…] as defined in clauses 2 and 9 […]

I see version numbers not containing any leading zeroes in clause 2, but that field has no other meaning anywhere in the specs, just numbers, so anything not under that rule must be invalid.

Clause 9 talks about pre-release identifiers, which could be either numeric identifiers and… non-numeric identifiers? Non-numeric identifiers is never called by name nor defined other than by defining numeric identifiers. The rest of the specs just implies its existence. Thus letting me believe anything that cannot be numeric identifier is a non-numeric identifier on a first read. (And non-numeric identifiers must exist, otherwise why would you specify that they can have letters and hyphen in them, if you would rule it out with the next statement.) And other than numeric identifiers not having leading zeroes, nothing more specific is stated for numeric identifiers and the non-numeric identifiers.

I was expecting something to the effect, that "an identifier consisting only of digits considered a numeric identifier" and "an identifier containing other than a digit is considered a non-numeric identifier" on top of what is in the specs (or rather "a numeric identifier MUST NOT contain any non-digits" and "an non-numeric identifier MUST HAVE at least one letter or hyphen in them"), as that is the only place where both digits and letters are present while also separate the identifiers as numeric and non-numeric/alphanumeric identifiers.

I was unable to deduct this from clause 9, don't see how clause 2 relates to this, and see no other clause contribute to this neither directly, nor indirectly.

Clause 11.4.2 states a group of identifiers having any letters or hyphens. Is this another clause that defines non-numeric identifiers?

Sorry for being difficult, I just don't want to leave this with "well, I don't understand, but everyone else says it's fine, so it must be!"

@jadaml commented on GitHub (Sep 5, 2021): > No single clause in the spec cant possibly rule in or out everything. […] That is understandable. Luckily I'm not asking of a single clause to rule in or out everything, just want to understand which one or more clauses together rule out `001` as pre-release identifiers. > […] A field containing only the ASCII code points for `0..9`, is a numeric field that must not have leading zeros, […] Since clause 9 defines pre-release identifiers with two meaning, this statement is insufficient in itself. See reasoning below. > […] as defined in clauses [2](https://semver.org/#spec-item-2) and [9](https://semver.org/#spec-item-9) […] I see version numbers not containing any leading zeroes in clause 2, but that field has no other meaning anywhere in the specs, just numbers, so anything not under that rule must be invalid. Clause 9 talks about pre-release identifiers, which could be either numeric identifiers and… non-numeric identifiers? Non-numeric identifiers is never called by name nor defined other than by defining numeric identifiers. The rest of the specs just implies its existence. Thus letting me believe anything that cannot be numeric identifier is a non-numeric identifier on a first read. (And non-numeric identifiers must exist, otherwise why would you specify that they can have letters and hyphen in them, if you would rule it out with the next statement.) And other than numeric identifiers not having leading zeroes, nothing more specific is stated for numeric identifiers and the non-numeric identifiers. I was expecting something to the effect, that "an identifier consisting only of digits considered a numeric identifier" and "an identifier containing other than a digit is considered a non-numeric identifier" on top of what is in the specs (or rather "a numeric identifier MUST NOT contain any non-digits" and "an non-numeric identifier MUST HAVE at least one letter or hyphen in them"), as that is the only place where both digits and letters are present while also separate the identifiers as numeric and non-numeric/alphanumeric identifiers. I was unable to deduct this from clause 9, don't see how clause 2 relates to this, and see no other clause contribute to this neither directly, nor indirectly. Clause 11.4.2 states a group of identifiers having any letters or hyphens. Is this another clause that defines non-numeric identifiers? Sorry for being difficult, I just don't want to leave this with "well, I don't understand, but everyone else says it's fine, so it must be!"

GiteaMirror commented

2026-02-17 12:02:37 -06:00

@jwdonahue commented on GitHub (Sep 5, 2021):

The spec references alphanumeric identifiers and numeric identifiers. While the set of all non-numeric identifiers would overlap alphanumeric identifiers, the reverse in this case, is not true. To qualify as alphanumeric under the spec, the identifier must have at least one non-numeric character, otherwise, it must comply with all of the rules for numeric fields. This is clearly stated in the BNF.

@jwdonahue commented on GitHub (Sep 5, 2021): The spec references _alphanumeric identifiers_ and _numeric identifiers_. While the set of all _non-numeric identifiers_ would overlap _alphanumeric identifiers_, the reverse in this case, is not true. To qualify as alphanumeric under the spec, the identifier must have at least one non-numeric character, otherwise, it must comply with all of the rules for numeric fields. This is clearly stated in the BNF.

GiteaMirror commented

2026-02-17 12:02:37 -06:00

@jadaml commented on GitHub (Sep 5, 2021):

The spec references alphanumeric identifiers and numeric identifiers. […]

I'm satisfied now that I know where is that specified (or probably it is night time here and I'm tired), as I can see now that the possible set of identifiers are implied with how it's called: numeric identifier and alphanumeric identifier.

What now I'm kind of missing is the actual mention of an alphanumeric identifier in the specs text, and not only in the BNF. Without this mention, whoever wants to follow this specs to the letter may not realize this is what you meant. They may not even consider examining the BNF after reading the specs whether it is considered a defining part of the specs or not.

I genuinely worried about passing this to a hypothetical colleague of mine that we should use this, and start a pointless fight over this semantics. It is harder to make an argument over a statement that was never written after all.

@jadaml commented on GitHub (Sep 5, 2021): > The spec references _alphanumeric identifiers_ and _numeric identifiers_. […] I'm satisfied now that I know where is that specified (or probably it is night time here and I'm tired), as I can see now that the possible set of identifiers are implied with how it's called: *numeric* identifier and *alphanumeric* identifier. What now I'm kind of missing is the *actual mention of an alphanumeric identifier* in the specs text, and not only in the BNF. Without this mention, whoever wants to follow this specs to the letter may not realize this is what you meant. They may not even consider examining the BNF after reading the specs whether it is considered a defining part of the specs or not. I genuinely worried about passing this to a hypothetical colleague of mine that we should use this, and start a pointless fight over this semantics. It is harder to make an argument over a statement that was never written after all.