[GH-ISSUE #308] Please allow omitting trailing .0, or document why not #2937

New Issue

GiteaMirror · 2026-04-25T17:04:18-05:00

GiteaMirror commented

2026-04-25 17:04:18 -05:00

Originally created by @joshtriplett on GitHub (May 22, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/308

I've often seen the question raised about why semver requires a three-component version number, MAJOR.MINOR.PATCH, even if PATCH is 0. I would suggest one of two things: either document that the version number may omit the trailing .0 if PATCH is 0, or add an entry to the FAQ at the end explaining why not.

Originally created by @joshtriplett on GitHub (May 22, 2016). Original GitHub issue: https://github.com/semver/semver/issues/308 I've often seen the question raised about why semver requires a three-component version number, MAJOR.MINOR.PATCH, even if PATCH is 0. I would suggest one of two things: either document that the version number may omit the trailing .0 if PATCH is 0, or add an entry to the FAQ at the end explaining why not.

GiteaMirror closed this issue

2026-04-25 17:04:18 -05:00

GiteaMirror commented

2026-04-25 17:04:18 -05:00

@FichteFoll commented on GitHub (May 22, 2016):

A normal version number MUST take the form X.Y.Z

spec item 2

That's pretty clear to me. People not used to reading specifications will always have problems reading them.

In the purpose of a FAQ, it could make sense to add this "clarification" however.

@FichteFoll commented on GitHub (May 22, 2016): > A normal version number MUST take the form X.Y.Z > - [spec item 2](http://semver.org/#spec-item-2) That's pretty clear to me. People not used to reading specifications will always have problems reading them. In the purpose of a FAQ, it _could_ make sense to add this "clarification" however.

GiteaMirror commented

2026-04-25 17:04:19 -05:00

@joshtriplett commented on GitHub (May 22, 2016):

I didn't suggest that the specification needs an update to state that this isn't allowed; the current spec very clearly disallows it. I'm suggesting that either the spec should allow this, or it should document the rationale for not allowing this.

@joshtriplett commented on GitHub (May 22, 2016): I didn't suggest that the specification needs an update to state _that_ this isn't allowed; the current spec very clearly disallows it. I'm suggesting that either the spec should allow this, or it should document the _rationale_ for not allowing this.

GiteaMirror commented

2026-04-25 17:04:19 -05:00

@haacked commented on GitHub (May 23, 2016):

The rationale is documented in the spec, but not directly.

These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software.

Keep in mind that SemVer describes the specification for libraries and packages. It does not dictate how you market your product. So your product is free to call itself "MyWidget 2.0" even if the library version is 2.0.0 or even 2.0.5.

Another reason for the current rule is to keep things as simple as possible for implementers. Allowing 2.0 and 2.0.0 to be equivalent adds unnecessary complexity. And then why not just 2?

@haacked commented on GitHub (May 23, 2016): The rationale is documented in the spec, but not directly. > These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software. Keep in mind that SemVer describes the specification for libraries and packages. It does not dictate how you _market_ your product. So your product is free to call itself "MyWidget 2.0" even if the library version is `2.0.0` or even `2.0.5`. Another reason for the current rule is to keep things as simple as possible for implementers. Allowing `2.0` and `2.0.0` to be equivalent adds unnecessary complexity. And then why not just `2`?

GiteaMirror commented

2026-04-25 17:04:19 -05:00

@joshtriplett commented on GitHub (May 23, 2016):

@Haacked "Keeping implementations simple" seems like a completely reasonable reason. Would you consider adding the explanation you just posted (especially the second half) as a FAQ answer?

@joshtriplett commented on GitHub (May 23, 2016): @Haacked "Keeping implementations simple" seems like a completely reasonable reason. Would you consider adding the explanation you just posted (especially the second half) as a FAQ answer?

GiteaMirror commented

2026-04-25 17:04:19 -05:00

@haacked commented on GitHub (May 23, 2016):

"Keeping implementations simple" seems like a completely reasonable reason. Would you consider adding the explanation you just posted (especially the second half) as a FAQ answer?

Honestly, this is the first time this question has come up as far as I can tell. And it doesn't seem like one that comes up often. If it comes up frequently, I'll reconsider. 😄

@haacked commented on GitHub (May 23, 2016): > "Keeping implementations simple" seems like a completely reasonable reason. Would you consider adding the explanation you just posted (especially the second half) as a FAQ answer? Honestly, this is the first time this question has come up as far as I can tell. And it doesn't seem like one that comes up often. If it comes up frequently, I'll reconsider. :smile:

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2937