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

System.OverflowException: 'Prerelease identifier 'xxx' was too large for Int32 in version 'xxx'.' #73

Closed
specialforest opened this issue Sep 2, 2022 · 9 comments

Comments

@specialforest
Copy link

An example version: "1.0.0-202208281200".
I don't see the spec limits pre-release numeric parts to 2^31 range.

@WalkerCodeRanger
Copy link
Owner

WalkerCodeRanger commented Sep 3, 2022

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)

@damepatr
Copy link

damepatr commented Jan 4, 2023

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.

@WalkerCodeRanger
Copy link
Owner

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

@damepatr
Copy link

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

@damepatr
Copy link

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.

@WalkerCodeRanger
Copy link
Owner

A preview of this feature has been released in the 3.0.0-beta.0 version available on NuGet.

@WalkerCodeRanger
Copy link
Owner

This has been fixed on master and will be included in v3.0.0

@Falco20019
Copy link

Falco20019 commented Aug 13, 2024

Is there a timeline on when 3.x is expected to be released? 3.0.0-beta.1 has been out for close to a year now. We have a internal guideline to not use pre-releases in our customer-facing software.

@WalkerCodeRanger
Copy link
Owner

I've just answered this in #83 . I'll try to get it out on or before 2024-09-30.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants