A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
It is unclear what exactly an integer is in terms of parsing and storage. I would assume the maximum would be a signed integer: 2^31 = 2147483648 but since negative numbers are not allowed other parsers may assume otherwise.
Originally created by @agentgt on GitHub (Apr 13, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/364
> A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
It is unclear what exactly an integer is in terms of parsing and storage. I would assume the maximum would be a signed integer: 2^31 = 2147483648 but since negative numbers are not allowed other parsers may assume otherwise.
It is unclear what exactly an integer is in terms of parsing and storage
First, only non-negative-integers (unsigned integers) are referenced in the spec. It would have been better to state it as positive integers, but either way, it's strongly defined in mathematics. The spec deliberately and rightly avoids implementation details such as which programming language to use or which data types. From an engineering perspective however, I think it would be absurd to use any kind of signed data types for the numeric fields.
Tool chain writers will think hard about their design choices or they will fail.
Please close this issue at your earliest possible convenience.
<!-- gh-comment-id:429046707 -->
@jwdonahue commented on GitHub (Oct 11, 2018):
@agentgt wrote
> It is unclear what exactly an integer is in terms of parsing and storage
First, only non-negative-integers (unsigned integers) are referenced in the spec. It would have been better to state it as positive integers, but either way, it's strongly defined in mathematics. The spec deliberately and rightly avoids implementation details such as which programming language to use or which data types. From an engineering perspective however, I think it would be absurd to use any kind of signed data types for the numeric fields.
Tool chain writers will think hard about their design choices or they will fail.
Please close this issue at your earliest possible convenience.
I'm fine with closing it. I don't really care that much and IIRC the issue I had was third party library decided to use a date for a version and the implementation failed because it was using Java 32 bit int (I think it was Java... it might have been python..).
So yeah I agree its the onus of the library to work correctly but some sort of max version length would be a good thing vs data types (and I believe somewhere there was talks of putting that in?).
<!-- gh-comment-id:429055549 -->
@agentgt commented on GitHub (Oct 11, 2018):
I'm fine with closing it. I don't really care that much and IIRC the issue I had was third party library decided to use a date for a version and the implementation failed because it was using Java 32 bit int (I think it was Java... it might have been python..).
So yeah I agree its the onus of the library to work correctly but some sort of max version length would be a good thing vs data types (and I believe somewhere there was talks of putting that in?).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @agentgt on GitHub (Apr 13, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/364
It is unclear what exactly an integer is in terms of parsing and storage. I would assume the maximum would be a signed integer: 2^31 = 2147483648 but since negative numbers are not allowed other parsers may assume otherwise.
@zafarkhaja commented on GitHub (Apr 13, 2017):
Seems like a duplicate of #304.
@jwdonahue commented on GitHub (Oct 11, 2018):
@agentgt wrote
First, only non-negative-integers (unsigned integers) are referenced in the spec. It would have been better to state it as positive integers, but either way, it's strongly defined in mathematics. The spec deliberately and rightly avoids implementation details such as which programming language to use or which data types. From an engineering perspective however, I think it would be absurd to use any kind of signed data types for the numeric fields.
Tool chain writers will think hard about their design choices or they will fail.
Please close this issue at your earliest possible convenience.
@agentgt commented on GitHub (Oct 11, 2018):
I'm fine with closing it. I don't really care that much and IIRC the issue I had was third party library decided to use a date for a version and the implementation failed because it was using Java 32 bit int (I think it was Java... it might have been python..).
So yeah I agree its the onus of the library to work correctly but some sort of max version length would be a good thing vs data types (and I believe somewhere there was talks of putting that in?).