Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed width version part alternative to spec. #255

Closed
travis-a-hoffman opened this issue May 19, 2015 · 7 comments
Closed

Fixed width version part alternative to spec. #255

travis-a-hoffman opened this issue May 19, 2015 · 7 comments
Labels
question Question about SemVer and use cases staled won't fix

Comments

@travis-a-hoffman
Copy link

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.

@FichteFoll
Copy link

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

@rlidwka
Copy link

rlidwka commented 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.

@travis-a-hoffman
Copy link
Author

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.

@FichteFoll
Copy link

@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.

@jwdonahue
Copy link
Contributor

@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.

@alexandrtovmach alexandrtovmach added the question Question about SemVer and use cases label Jun 10, 2020
@alexandrtovmach
Copy link
Member

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

@alexandrtovmach
Copy link
Member

👻 👻 👻
Closed as staled

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Question about SemVer and use cases staled won't fix
Projects
None yet
Development

No branches or pull requests

5 participants