semver
semver copied to clipboard
maxhauser
System.OverflowException: 'Prerelease identifier 'xxx' was too large for Int32 in version 'xxx'.'
An example version: "1.0.0-202208281200". I don't see the spec limits pre-release numeric parts to 2^31 range.
The semver spec does not give an upper limit to numeric prerelease identifiers nor for the major, minor, or patch. However, for ease of developer use int was used for these. It was thought unlikely people would run into those limits. For v3.0 of the library, we can consider using long or BigInteger.
In the mean time, I would suggest turning it into an alphanumeric prerelease identifier following the ISO 8601 standard (e.g. 1.0.0-2022-08-28.1200) or dot separating each of the parts (e.g. 1.0.0-2022.08.28.1200)
The semver spec does not give an upper limit to numeric prerelease identifiers nor for the major, minor, or patch.
Yeah, I am encountering the same issue with the patch number. I would definitely be interested in a fix.
@damepatr To help me understand the use case and how to best address it, how are you getting patch numbers so high? Also, what is the highest patch number you would anticipate needing?
@WalkerCodeRanger
To help me understand the use case and how to best address it, how are you getting patch numbers so high?
I used the date and time to create a patch number similar to the following: 1.1.20221227164407.
I know that this probably isn't a best practice. I was just testing some of my own code and I noticed that SemVersion.TryParse was returning false when this technically is valid SemVer.
Also, what is the highest patch number you would anticipate needing?
At the moment, I'm not certain. I may not need a larger patch number.
A preview of this feature has been released in the 3.0.0-beta.0 version available on NuGet.