This project is read-only.

NuGet imposes artificial max string length of 20 characters for "SpecialVersion" (aka pre-release)


Just ran into a problem where we have a base pre-release identifier of something like 16 characters, but then, in order to create a newer version, we usually append a yyyyMMddbb string to those which send it over 20 characters and got an InvalidOperationException from NuGet telling me it exceeds 20 characters.

The offending logic is in PackageBuilder::ValidateSpecialVersionLength which is called by PackageBuilder::Save. I see no mention of a maximum string length for pre-release identifiers in the SemVer specification (either v1 or the new v2), therefore this check should not even exist. The only mention in the v2 spec is that the entire version string should not exceed 255 characters in total string length.


dmarsh wrote Jun 21, 2013 at 7:20 PM

PR submitted.

dotnetjunky wrote Jun 22, 2013 at 12:30 AM

We think 20 characters is sufficient for the special string. Changing it now will also require changing the code on to accommodate for longer string.

Please modify your build so that it fits into 20 characters limit.

dotnetjunky wrote Jun 22, 2013 at 12:30 AM

** Closed by dotnetjunky 06/21/2013 4:30PM

dmarsh wrote Jun 22, 2013 at 12:54 AM

We have changed our identifier already, so this is a forward thinking recommendation.

It seems odd to me that the NuGet team to declare that 20 characters is enough for everybody in the world, especially when supposedly trying to abide by SemVer versioning rules which has no such specified restriction. Now, maybe you want to impose the restriction for itself and, ok, that's totally up to you. In fact, for my use case (and probably that of many others), I'm not publishing my pre-release packages to the official NuGet feed anyway. However, I don't see why such a limitation it needs to be imposed within in NuGet Core such that third parties can't even build their own packages with IDs of their choosing.

The truth is this only a bigger problem for because I'm forced to append a build number to the static pre-release identifier. Once NuGet has support for SemVer 2.0 build #s this will probably become a non-issue for me, though I still see no good reason to impose the restriction in NuGet Core.

JeffHandley wrote Jun 22, 2013 at 3:10 AM

Thanks for raising this as an issue and sharing your feedback. This is something I brought up within the SemVer spec itself, which led to that 255-character total length limit.

While we have an arbitrary length limit now, I'm not comfortable just picking another (longer) arbitrary limit at the moment. We'll be thinking about SemVer 2.0 support and it would be best to define a new length as part of the spec for that.

PombeirP wrote Feb 19, 2014 at 2:58 PM

+1. This makes us jumps through hoops with our internal builds since we can't convey our feature branch names consistently.

Jo8n wrote Aug 19, 2014 at 10:32 PM

We've also run into trouble with this for our internal builds and packages. By the time we include the defect number, we only have 12 characters for other info. If this is merely because longer values are "ugly", as 1639 implies, that seems very arbitrary and I would think ugliness should be handled in presentation.

CaioProiete wrote Sep 7, 2014 at 2:50 AM

@dotnetjunky: Could we revisit this, please?

Would be great to remove this limitation of 20 chars which hurts a lot of people building NuGet packages for feature branches (where branch name is included as part of the "SpecialVersion".


Of course we can truncate it, but then there's much less value as you can't tell immediately what the package is/has:

Caio Proiete

ianbattersby wrote Sep 22, 2014 at 10:12 AM

+1 - Please don't enforce an artificial limit, or at least provide an override flag. This is now killing my chosen workflow because I'm a couple of characters over :(

samshiles wrote Mar 12, 2015 at 4:24 PM

This is crazy. Please remove this restriction or at least come up with a justification based on more than "we said so".

idavis wrote Jul 15, 2016 at 3:04 PM

Can we bump this? Is the hold up really just people don't want to migrate/update the database?