[GH-ISSUE #112] Is 0000001.0000002.00300003 a valid semver or not? #5192

New Issue

GiteaMirror · 2026-06-15T11:11:21-05:00

GiteaMirror commented

2026-06-15 11:11:21 -05:00

Originally created by @isaacs on GitHub (Jun 12, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/112

Came up in the discussions in #110.

Are leading zeroes allowed or not?

I think that they shouldn't be allowed, because it's strange to me that 0000001.0000002.00300003 would be functionally identical to 1.2.300003.

Same for numeric prerelease identifiers. Is 1.2.3-beta.000000000000009 the same as 1.2.3-beta.9 and 1.2.3-beta.09?

If leading zeros ARE allowed, then it should be made explicit. I'd assumed that they weren't allowed, and I doubt whether most SemVer parsers do allow them, at least in the main version.

In other words, I'm suggesting that the regular expression for major/minor/patch version segments would be something like /^[1-9]\d*|0$/.

Originally created by @isaacs on GitHub (Jun 12, 2013). Original GitHub issue: https://github.com/semver/semver/issues/112 Came up in the discussions in #110. Are leading zeroes allowed or not? I think that they shouldn't be allowed, because it's strange to me that `0000001.0000002.00300003` would be functionally identical to `1.2.300003`. Same for numeric prerelease identifiers. Is `1.2.3-beta.000000000000009` the same as `1.2.3-beta.9` and `1.2.3-beta.09`? If leading zeros ARE allowed, then it should be made explicit. I'd assumed that they weren't allowed, and I doubt whether most SemVer parsers do allow them, at least in the main version. In other words, I'm suggesting that the regular expression for major/minor/patch version segments would be something like `/^[1-9]\d*|0$/`.

GiteaMirror closed this issue

2026-06-15 11:11:21 -05:00

GiteaMirror commented

2026-06-15 11:11:22 -05:00

@EddieGarmon commented on GitHub (Jun 12, 2013):

Leading zeros SHOULD NOT be allowed for major, minor, patch.
leading zeros SHOULD be allowed in prerelease and other metadata.

@EddieGarmon commented on GitHub (Jun 12, 2013): Leading zeros SHOULD NOT be allowed for major, minor, patch. leading zeros SHOULD be allowed in prerelease and other metadata.

GiteaMirror commented

2026-06-15 11:11:23 -05:00

@petermichaux commented on GitHub (Jun 12, 2013):

If leading zeros in the major, minor, and patch are allowed then I think the spec should say they have no meaning in comparing versions. If they have no meaning then they are not semantic and so allowing them is questionable in a standard called "semantic version"

I think the most important part is clarity.

@petermichaux commented on GitHub (Jun 12, 2013): If leading zeros in the major, minor, and patch are allowed then I think the spec should say they have no meaning in comparing versions. If they have no meaning then they are not semantic and so allowing them is questionable in a standard called "semantic version" I think the most important part is clarity.

GiteaMirror commented

2026-06-15 11:11:23 -05:00

@tbull commented on GitHub (Jun 12, 2013):

Is 0000001.0000002.00300003 a valid semver or not?

According to the current spec, it's valid.

Your example is a bit extreme. Albeit allowed, nobody would seriously go that far. A single leading zero in the minor part as in 1.09.2, however, could be seen as useful. I admit, use cases seem rather limited. Yet, any constraint should always be there for a good reason. I, personally, would not consider your example of possible abuse a good enough reason. But that's probably a matter of taste.

Same for numeric prerelease identifiers. Is 1.2.3-beta.000000000000009 the same as 1.2.3-beta.9 and 1.2.3-beta.09?

Again: yes. This has indeed led to the addition of some considerable amount of thought and code in my current implementation. I brought this up some time ago as an "implementation note" in #88.

Leading zeros SHOULD NOT be allowed for major, minor, patch.
leading zeros SHOULD be allowed in prerelease and other metadata.

This is the worst option because it's inconsistent and thereby makes life for implementors even harder.

@tbull commented on GitHub (Jun 12, 2013): > Is 0000001.0000002.00300003 a valid semver or not? According to the current spec, it's valid. Your example is a bit extreme. Albeit allowed, nobody would seriously go that far. A single leading zero in the minor part as in `1.09.2`, however, could be seen as useful. I admit, use cases seem rather limited. Yet, any constraint should always be there for a good reason. I, personally, would not consider your example of possible abuse a good enough reason. But that's probably a matter of taste. > Same for numeric prerelease identifiers. Is 1.2.3-beta.000000000000009 the same as 1.2.3-beta.9 and 1.2.3-beta.09? Again: yes. This has indeed led to the addition of some considerable amount of thought and code in my current implementation. I brought this up some time ago as an "implementation note" in #88. > Leading zeros SHOULD NOT be allowed for major, minor, patch. > leading zeros SHOULD be allowed in prerelease and other metadata. This is the worst option because it's inconsistent and thereby makes life for implementors even harder.

GiteaMirror commented

2026-06-15 11:11:24 -05:00

@isaacs commented on GitHub (Jun 12, 2013):

I agree with @tbull and @petermichaux that it should be clarified in the specification.

However, we are in disagreement about whether leading zeroes should be allowed at all. There's no sense going back and forth re-making our cases, it's just bikeshedding at this point.

Who's the person to make a decision on this definitively? @Haacked? @mojombo? We need a dictatorial action :)

@isaacs commented on GitHub (Jun 12, 2013): I agree with @tbull and @petermichaux that it should be clarified in the specification. However, we are in disagreement about whether leading zeroes should be allowed at all. There's no sense going back and forth re-making our cases, it's just bikeshedding at this point. Who's the person to make a decision on this definitively? @Haacked? @mojombo? We need a dictatorial action :)

GiteaMirror commented

2026-06-15 11:11:25 -05:00

@petermichaux commented on GitHub (Jun 12, 2013):

I believe that leading zeros should not be allowed in major, minor, and patch which is why I wrote the BNF the way I did in #110

@petermichaux commented on GitHub (Jun 12, 2013): I believe that leading zeros should not be allowed in major, minor, and patch which is why I wrote the BNF the way I did in #110

GiteaMirror commented

2026-06-15 11:11:26 -05:00

@tbull commented on GitHub (Jun 12, 2013):

Ok, let's wait for a dictator to show up... ;-)

@tbull commented on GitHub (Jun 12, 2013): Ok, let's wait for a dictator to show up... ;-)

GiteaMirror commented

2026-06-15 11:11:26 -05:00

@haacked commented on GitHub (Jun 13, 2013):

I'm going to confer with @mojombo on this one, but my take is it shouldn't be allowed in Major.Minor.Patch.

I tend to favor this:

Leading zeros SHOULD NOT be allowed for major, minor, patch.
leading zeros SHOULD be allowed in prerelease and other metadata.

I know it's a bit inconsistent, but we've always had slightly different rules for pre-release identifiers than for Major, Minor, Patch so I'm not too concerned about that.

@haacked commented on GitHub (Jun 13, 2013): I'm going to confer with @mojombo on this one, but my take is it shouldn't be allowed in Major.Minor.Patch. I tend to favor this: > Leading zeros SHOULD NOT be allowed for major, minor, patch. > leading zeros SHOULD be allowed in prerelease and other metadata. I know it's a bit inconsistent, but we've always had slightly different rules for pre-release identifiers than for Major, Minor, Patch so I'm not too concerned about that.

GiteaMirror commented

2026-06-15 11:11:27 -05:00

@domenic commented on GitHub (Jun 13, 2013):

@Haacked OK, so in that world, what's the answer to

Is 1.2.3-beta.000000000000009 the same as 1.2.3-beta.9 and 1.2.3-beta.09?

I'd guess beta numbers are lexical, so it's 1.2.3-beta.000000000000009 < 1.2.3-beta.09 < 1.2.3-beta.9 ?

@domenic commented on GitHub (Jun 13, 2013): @Haacked OK, so in that world, what's the answer to > Is `1.2.3-beta.000000000000009` the same as `1.2.3-beta.9` and `1.2.3-beta.09`? I'd guess beta numbers are lexical, so it's `1.2.3-beta.000000000000009` < `1.2.3-beta.09` < `1.2.3-beta.9` ?

GiteaMirror commented

2026-06-15 11:11:28 -05:00

@haacked commented on GitHub (Jun 13, 2013):

I think we have to compare them as integers. Otherwise: 1.2.3-beta.09 < 1.2.3-beta.1 which goes against expectations. Right now, if a pre-release identifier only contains integers, we use integer comparison.

@haacked commented on GitHub (Jun 13, 2013): I think we have to compare them as integers. Otherwise: `1.2.3-beta.09` < `1.2.3-beta.1` which goes against expectations. Right now, if a pre-release identifier only contains integers, we use integer comparison.

GiteaMirror commented

2026-06-15 11:11:28 -05:00

@domenic commented on GitHub (Jun 13, 2013):

OK, so 1.2.3-beta.000000000000009 = 1.2.3-beta.09 = 1.2.3-beta.9?

@domenic commented on GitHub (Jun 13, 2013): OK, so `1.2.3-beta.000000000000009 = 1.2.3-beta.09 = 1.2.3-beta.9`?

GiteaMirror commented

2026-06-15 11:11:29 -05:00

@haacked commented on GitHub (Jun 13, 2013):

BTW, I can see how that's a bit weird. Allowing leading 0s certainly keeps things simpler.

Alternatively (and I throw this out for completeness), we could have pre-release identifiers be:

([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*)

In other words, if a pre-release identifier is only digits, it cannot have leading zeroes. Not sure I like that because it seems overly complicated.

Also, it occurs to me that the spec allows - anywhere in a pre-release identifier, right? So 1.0.0-- is valid with the pre-release being -. ;)

@haacked commented on GitHub (Jun 13, 2013): BTW, I can see how that's a bit weird. Allowing leading 0s certainly keeps things simpler. Alternatively (and I throw this out for completeness), we could have pre-release identifiers be: `([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*)` In other words, if a pre-release identifier is only digits, it cannot have leading zeroes. Not sure I like that because it seems overly complicated. Also, it occurs to me that the spec allows `-` anywhere in a pre-release identifier, right? So `1.0.0--` is valid with the pre-release being `-`. ;)

GiteaMirror commented

2026-06-15 11:11:30 -05:00

@haacked commented on GitHub (Jun 13, 2013):

@domenic that's what I think it should be, yes.

@haacked commented on GitHub (Jun 13, 2013): @domenic that's what I think it should be, yes.

GiteaMirror commented

2026-06-15 11:11:30 -05:00

@domenic commented on GitHub (Jun 13, 2013):

In other words, if a pre-release identifier is only digits, it cannot have leading zeroes. Not sure I like that because it seems overly complicated.

This would be nicer IMO, not sure about how others in the thread feel. Mainly because having a canonical pre-release identifier seems better, instead of letting you prepend a 0 and get a new way of saying the same identifier.

@domenic commented on GitHub (Jun 13, 2013): > In other words, if a pre-release identifier is only digits, it cannot have leading zeroes. Not sure I like that because it seems overly complicated. This would be nicer IMO, not sure about how others in the thread feel. Mainly because having a canonical pre-release identifier seems better, instead of letting you prepend a `0` and get a new way of saying the same identifier.

GiteaMirror commented

2026-06-15 11:11:31 -05:00

@petermichaux commented on GitHub (Jun 13, 2013):

([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*) does not allow patch like "-alpha.0.1.0" where some are just zero. It also doesn't allow "-alpha.0foo".

@petermichaux commented on GitHub (Jun 13, 2013): `([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*)` does not allow patch like "-alpha.0.1.0" where some are just zero. It also doesn't allow "-alpha.0foo".

GiteaMirror commented

2026-06-15 11:11:32 -05:00

@haacked commented on GitHub (Jun 13, 2013):

@petermichaux nice catch. My regex fu is weak sauce today. How's this?

(0)|([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*)

@haacked commented on GitHub (Jun 13, 2013): @petermichaux nice catch. My regex fu is weak sauce today. How's this? ``` (0)|([1-9]\d*)|([a-zA-Z1-9-][a-zA-Z0-9-]*) ```

GiteaMirror commented

2026-06-15 11:11:33 -05:00

@isaacs commented on GitHub (Jun 13, 2013):

No need for the triple-capture. If you have a system (such as JavaScript) supporting negative lookahead, you can do it this way, which is closer to the "spirit" of what the spec would say: /(?!^0\d+$)(^[a-zA-Z0-9-]+$)/. In other words, "Any combination of letters, numbers, and hyphens, except a purely numeric identifier containing leading zeroes."

> r = /(?!^0\d+$)(^[a-zA-Z0-9-]+$)/
/(?!^0\d+$)(^[a-zA-Z0-9-]+$)/
> r.test('0')
true
> r.test('asdf0foo')
true
> r.test('a-b-c')
true
> r.test('100')
true
> r.test('0100')
false

@isaacs commented on GitHub (Jun 13, 2013): No need for the triple-capture. If you have a system (such as JavaScript) supporting negative lookahead, you can do it this way, which is closer to the "spirit" of what the spec would say: `/(?!^0\d+$)(^[a-zA-Z0-9-]+$)/`. In other words, "Any combination of letters, numbers, and hyphens, except a purely numeric identifier containing leading zeroes." ``` > r = /(?!^0\d+$)(^[a-zA-Z0-9-]+$)/ /(?!^0\d+$)(^[a-zA-Z0-9-]+$)/ > r.test('0') true > r.test('asdf0foo') true > r.test('a-b-c') true > r.test('100') true > r.test('0100') false ```

GiteaMirror commented

2026-06-15 11:11:33 -05:00

@mojombo commented on GitHub (Jun 13, 2013):

Leading zeros seem like YAGNI to me and only serve to open up confusing comparisons and precedence mistakes. The spec is already quite restrictive on what is valid so forbidding leading zeros doesn't strike me as inconsistent and nicely renders all of these nuanced decisions moot.

Part of my vision for SemVer is to prevent people from having to think about stuff that doesn't matter, and contemplating how leading zeros affect precedence is something that doesn't matter.

@mojombo commented on GitHub (Jun 13, 2013): Leading zeros seem like YAGNI to me and only serve to open up confusing comparisons and precedence mistakes. The spec is already quite restrictive on what is valid so forbidding leading zeros doesn't strike me as inconsistent and nicely renders all of these nuanced decisions moot. Part of my vision for SemVer is to prevent people from having to think about stuff that doesn't matter, and contemplating how leading zeros affect precedence is something that doesn't matter.

GiteaMirror commented

2026-06-15 11:11:34 -05:00

@isaacs commented on GitHub (Jun 13, 2013):

@mojombo So the decision is "no leading zeroes" then? +01 to that ;)

@isaacs commented on GitHub (Jun 13, 2013): @mojombo So the decision is "no leading zeroes" then? +01 to that ;)

GiteaMirror commented

2026-06-15 11:11:35 -05:00

@mojombo commented on GitHub (Jun 13, 2013):

Oh, another reason to forbid leading zeros is because it then allows two valid (non-build) versions to have identical precedence which means more undefined behavior in tools that care about this stuff.

@mojombo commented on GitHub (Jun 13, 2013): Oh, another reason to forbid leading zeros is because it then allows two valid (non-build) versions to have identical precedence which means more undefined behavior in tools that care about this stuff.

GiteaMirror commented

2026-06-15 11:11:36 -05:00

@haacked commented on GitHub (Jun 14, 2013):

@mojombo What about for pre-release identifiers? Based on what you said, we should probably not allow leading 0s for pre-release identifiers that only contain digits, right?

1.0.0-alpha.001 vs 1.0.0-alpha.1?

@haacked commented on GitHub (Jun 14, 2013): @mojombo What about for pre-release identifiers? Based on what you said, we should probably not allow leading 0s for pre-release identifiers that _only_ contain digits, right? `1.0.0-alpha.001` vs `1.0.0-alpha.1`?

GiteaMirror commented

2026-06-15 11:11:37 -05:00

@mojombo commented on GitHub (Jun 15, 2013):

@Haacked Correct. 1.0.0-alpha.001 would not be valid.

@mojombo commented on GitHub (Jun 15, 2013): @Haacked Correct. `1.0.0-alpha.001` would not be valid.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5192