Fixed width version part alternative to spec. #179

New Issue

GiteaMirror · 2026-02-17T11:30:36-06:00

GiteaMirror commented

2026-02-17 11:30:36 -06:00

Originally created by @travis-a-hoffman on GitHub (May 19, 2015).

Where I work, and for many, tomcat is used to serve up wars. Traditionally, wars are named: foo-max.min.build.war. Unfortunately, Tomcat does alphabetic comparison to evaluate when to replace a war. In this case, version foo-1.2.9.war is evaluated as being a version after foo-1.2.10.war, and thus tomcat won't automatically do the update.

The workaround we've found to be simplest and most inline with Semantic Versioning is to use fixed width fields, such as 1.02.0009, or 1.002.009 to delay (and make less likely) the decimal overflow of an individual field. It's not ideal, but it works for this situation. It would be nice to make this an optional or variation of the spec.

Originally created by @travis-a-hoffman on GitHub (May 19, 2015). Where I work, and for many, tomcat is used to serve up wars. Traditionally, wars are named: foo-max.min.build.war. Unfortunately, Tomcat does alphabetic comparison to evaluate when to replace a war. In this case, version foo-1.2.9.war is evaluated as being a version after foo-1.2.10.war, and thus tomcat won't automatically do the update. The workaround we've found to be simplest and most inline with Semantic Versioning is to use fixed width fields, such as 1.02.0009, or 1.002.009 to delay (and make less likely) the decimal overflow of an individual field. It's not ideal, but it works for this situation. It would be nice to make this an optional or variation of the spec.

GiteaMirror added the question staled won't fix labels 2026-02-17 11:30:37 -06:00

GiteaMirror closed this issue

2026-02-17 11:30:38 -06:00

GiteaMirror commented

2026-02-17 11:30:40 -06:00

@FichteFoll commented on GitHub (May 20, 2015):

Imo this takes away some of the uniformity of semvers. A stricter standard is usually the better option unless flexibility is required by many. Most programming languages don't allow for numeric literals with leading zeros either.

BTW, I thin this was explicitly added after 2.0.0-rc.2

@FichteFoll commented on GitHub (May 20, 2015): Imo this takes away some of the uniformity of semvers. A stricter standard is usually the better option unless flexibility is required by many. Most programming languages don't allow for numeric literals with leading zeros either. BTW, I thin this was explicitly added after 2.0.0-rc.2

GiteaMirror commented

2026-02-17 11:30:40 -06:00

@rlidwka commented on GitHub (May 20, 2015):

I think semver should define the meaning of those numbers, not an actual format. So I would still consider 1.02.0009 a semver, and even I.II.IX is as long as release policy is appropriate.

@rlidwka commented on GitHub (May 20, 2015): I think semver should define the _meaning_ of those numbers, not an actual format. So I would still consider `1.02.0009` a semver, and even `I.II.IX` is as long as release policy is appropriate.

GiteaMirror commented

2026-02-17 11:30:41 -06:00

@travis-a-hoffman commented on GitHub (Jul 20, 2015):

Thanks for the feedback, I think I understand a bit more about semver. I might humbly suggest a clarifying note as an attachment to, but not part of, the spec explaining how to approach these sorts of variations while keeping with the spirit/vision of semver.

@travis-a-hoffman commented on GitHub (Jul 20, 2015): Thanks for the feedback, I think I understand a bit more about semver. I might humbly suggest a clarifying note as an attachment to, but not part of, the spec explaining how to approach these sorts of variations while keeping with the spirit/vision of semver.

GiteaMirror commented

2026-02-17 11:30:42 -06:00

@FichteFoll commented on GitHub (Jul 20, 2015):

@rlidwka unfortunately, that would complicate parsing a lot, and unnecessarily. Most people are using 0x30 to 0x39 as decimal digits anyway, and allowing leading zeroes raises the question whether 9 and 000009 are equal or unequal.
It has a unique answer for pre-release and metadata identifiers (where "9" is greater than "00...0009" because 9 has a higher character order), but not the one you would expect when comparing 9 against 010.

@FichteFoll commented on GitHub (Jul 20, 2015): @rlidwka unfortunately, that would complicate parsing a lot, and unnecessarily. Most people are using 0x30 to 0x39 as decimal digits anyway, and allowing leading zeroes raises the question whether `9` and `000009` are equal or unequal. It has a unique answer for pre-release and metadata identifiers (where `"9"` is greater than `"00...0009"` because `9` has a higher character order), but not the one you would expect when comparing `9` against `010`.

GiteaMirror commented

2026-02-17 11:30:42 -06:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@travis-a-hoffman, how you map SemVer strings to/from other formats is a tool design issue and out of scope for SemVer. Unless you have further questions, comments or intend to issue a PR for this, please close this issue.

@jwdonahue commented on GitHub (Dec 8, 2017): @travis-a-hoffman, how you map SemVer strings to/from other formats is a tool design issue and out of scope for SemVer. Unless you have further questions, comments or intend to issue a PR for this, please close this issue.

GiteaMirror commented

2026-02-17 11:30:43 -06:00

@alexandrtovmach commented on GitHub (Jun 10, 2020):

This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing 🎆

@alexandrtovmach commented on GitHub (Jun 10, 2020): This issue looks staled and will be closed in 10 days if there are no objections. Thanks everyone for contributions, you're amazing :fireworks:

GiteaMirror commented

2026-02-17 11:30:44 -06:00

@alexandrtovmach commented on GitHub (Jun 19, 2020):

👻 👻 👻
Closed as staled

@alexandrtovmach commented on GitHub (Jun 19, 2020): 👻 👻 👻 Closed as staled