Clarifying Lexical Comparison for Identifier Precedence #544

New Issue

GiteaMirror · 2026-02-17T12:12:21-06:00

GiteaMirror commented

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

Originally created by @Andrei15193 on GitHub (May 5, 2022).

Hi,

In the specifications it is mentioned that precedence between identifiers that are not made out of digits (not numbers, basically) is determined by lexical comparison, however I am unsure how this applies to an edge case where one identifier is in the beginning of another identifier. For instance, if I have 1.0.0-alpha and 1.0.0-alpha-prep, which one has precedence? Is it 1.0.0-alpha < 1.0.0-alpha-prep or 1.0.0-alpha-prep < 1.0.0-alpha?

Please include a case like this in the precedence example on the landing page, just for clarification.

Thanks!

Originally created by @Andrei15193 on GitHub (May 5, 2022). Hi, In the specifications it is mentioned that precedence between identifiers that are not made out of digits (not numbers, basically) is determined by lexical comparison, however I am unsure how this applies to an edge case where one identifier is in the beginning of another identifier. For instance, if I have `1.0.0-alpha` and `1.0.0-alpha-prep`, which one has precedence? Is it `1.0.0-alpha < 1.0.0-alpha-prep` or `1.0.0-alpha-prep < 1.0.0-alpha`? Please include a case like this in the precedence example on the landing page, just for clarification. Thanks!

GiteaMirror closed this issue

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

GiteaMirror commented

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

@jwdonahue commented on GitHub (May 11, 2022):

See 11.4.4:

A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal

@jwdonahue commented on GitHub (May 11, 2022): See [11.4.4](https://semver.org/#spec-item-11): > A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal

GiteaMirror commented

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

@Andrei15193 commented on GitHub (May 11, 2022):

But in this case the set of pre-release fields is the same size. The pre-release identifiers are alpha and alpha-prep. We can use a different example, 1.0.0-alpha and 1.0.0-alphaPrep, which one has precedence in this case? alpha or alphaPrep?

@Andrei15193 commented on GitHub (May 11, 2022): But in this case the set of pre-release fields is the same size. The pre-release identifiers are `alpha` and `alpha-prep`. We can use a different example, `1.0.0-alpha` and `1.0.0-alphaPrep`, which one has precedence in this case? `alpha` or `alphaPrep`?

GiteaMirror commented

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

@jwdonahue commented on GitHub (May 11, 2022):

Oh sorry. Alpha-prep is not two fields, my bad. The longer string is greater than the shorter one where they share a common prefix, so -alpha < -alphaPrep.

Standard lexical comparison. The standard libraries or built in string operators of every 3G language applies the same rules. The algorithm is more than a hundred years old.

a < b < ab < c

@jwdonahue commented on GitHub (May 11, 2022): Oh sorry. Alpha-prep is not two fields, my bad. The longer string is greater than the shorter one where they share a common prefix, so -alpha < -alphaPrep. [Standard lexical comparison](https://www.cplusplus.com/reference/algorithm/lexicographical_compare/#:~:text=A%20lexicographical%20comparison%20is%20the,not%20equivalent%20to%20the%20other.). The standard libraries or built in string operators of every 3G language applies the same rules. The algorithm is more than a hundred years old. ----- a < b < ab < c

GiteaMirror commented

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

@Andrei15193 commented on GitHub (May 11, 2022):

Was guessing that it's like that, but wanted to make sure.

Alright, that clarifies it for me, thank you 😃

@Andrei15193 commented on GitHub (May 11, 2022): Was guessing that it's like that, but wanted to make sure. Alright, that clarifies it for me, thank you 😃

GiteaMirror commented

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

@jwdonahue commented on GitHub (May 11, 2022):

It gets way more complicated with unicode and semantically equivalent, but different codes. Hence the ASCII restriction.

@jwdonahue commented on GitHub (May 11, 2022): It gets way more complicated with unicode and semantically equivalent, but different codes. Hence the ASCII restriction.

GiteaMirror commented

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

@jwdonahue commented on GitHub (May 11, 2022):

@Andrei15193 Apologies for the confusion. I must have been more tired last night than I thought. a < b < ab < c is incorrect.

I thought I fixed it, but apparently made the same mistake twice. Good thing I skimmed my emails this morning. I have edited the original, and to be clear it should have been:

a < b < ba < c

Just like in a dictionary.

@jwdonahue commented on GitHub (May 11, 2022): @Andrei15193 Apologies for the confusion. I must have been more tired last night than I thought. `a < b < ab < c` **is incorrect**. I thought I fixed it, but apparently made the same mistake twice. Good thing I skimmed my emails this morning. I have edited the original, and to be clear it should have been: a < b < ba < c Just like in a dictionary.

GiteaMirror commented

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

@Andrei15193 commented on GitHub (May 11, 2022):

Oh, I totally missed that, I was too focused on the a < ab comparison. Thanks for looking it up! I've edited the comments and removed the quotes.

@Andrei15193 commented on GitHub (May 11, 2022): Oh, I totally missed that, I was too focused on the `a < ab` comparison. Thanks for looking it up! I've edited the comments and removed the quotes.