Why are version numbers typically “2.1.3” instead of 2.13?
Seems like the latter makes more sense, since you can run numerical comparators over it.
Why are version numbers typically 2.1.3 instead of 2.13? Seems like the latter makes
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Why are version numbers typically “2.1.3” instead of 2.13?
Seems like the latter makes more sense, since you can run numerical comparators over it.
For the same reason that when the version number is encoded into an integer (e.g. Python’s sys.hexversion), it’s padded with zeroes:
You frequently have to go beyond 10.
Many projects adopt a major.minor.bugfix scheme (e.g. Semantic Versioning). Maybe version 2.1.9 has a security hole which need to patch; you’d need to call it 2.1.10 (because calling it 2.2.0 implies new features and possible minor incompatibilities). Maybe version 3 completely changes the syntax so you want to continue to add features to version 2.
Maybe your project simply releases so frequently that you have more than 100 minor/bugfix versions per major version (kernel.org lists 2.6.34.14 and 3.0.60).
Finally, it’s a string. Sure, you can parse it into a double for comparison purposes, but plenty of languages/libraries support “numeric” string comparisons (so “Document 9” comes before “Document 10”); Apache’s mod_autoindex even calls it “VersionSort”.