[GH-ISSUE #364] What is the maximum version number size (ie unsigned integer, signed long?) #4515

New Issue

GiteaMirror · 2026-06-13T12:41:25-05:00

GiteaMirror commented

2026-06-13 12:41:25 -05:00

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.

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.

GiteaMirror closed this issue

2026-06-13 12:41:25 -05:00

GiteaMirror commented

2026-06-13 12:41:26 -05:00

@zafarkhaja commented on GitHub (Apr 13, 2017):

Seems like a duplicate of #304.

@zafarkhaja commented on GitHub (Apr 13, 2017): Seems like a duplicate of #304.

GiteaMirror commented

2026-06-13 12:41:27 -05:00

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

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

GiteaMirror commented

2026-06-13 12:41:30 -05:00

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

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

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4515