What string length should implementers use for semver version strings? #59

New Issue

GiteaMirror · 2026-02-17T11:07:02-06:00

GiteaMirror commented

2026-02-17 11:07:02 -06:00

Originally created by @jeffhandley on GitHub (Mar 15, 2013).

For systems like nuget.org where version strings are stored in a database, we need to know how long version strings can get. Presently, nuget.org implements a 64-character limit on version strings. With build metadata being added in, it's expected that version strings will get longer, but by how much?

The spec should define a maximum version string length and/or a maximum length for each segment of the version number.

Originally created by @jeffhandley on GitHub (Mar 15, 2013). For systems like nuget.org where version strings are stored in a database, we need to know how long version strings can get. Presently, nuget.org [implements](https://github.com/NuGet/NuGetGallery/blob/master/Website/Entities/Package.cs#L96) a 64-character limit on version strings. With build metadata being added in, it's expected that version strings will get longer, but by how much? The spec should define a maximum version string length and/or a maximum length for each segment of the version number.

GiteaMirror closed this issue

2026-02-17 11:07:02 -06:00

GiteaMirror commented

2026-02-17 11:07:03 -06:00

@haacked commented on GitHub (May 6, 2013):

Ugh. Got a proposed max length? I can't put a finger on why this makes me uneasy.

@haacked commented on GitHub (May 6, 2013): Ugh. Got a proposed max length? I can't put a finger on why this makes me uneasy.

GiteaMirror commented

2026-02-17 11:07:03 -06:00

@jeffhandley commented on GitHub (May 6, 2013):

Here's my recommendation:

Major Version, Min Version, Patch: Values 0-65535 (5 + 1 + 5 + 1 + 5 = 17)
Prerelease label: Up to 64 characters (not including the -)
Build metadata: Up to 64 characters (not including the +)

Total length for these parts: 17 + 1 + 64 + 1 + 64 = 147

It makes you uneasy because we don't like arbitrary limits. But the implications of not having limits on this can really cause harm. A 147-character field will allow for decent indexing.

@jeffhandley commented on GitHub (May 6, 2013): Here's my recommendation: 1. Major Version, Min Version, Patch: Values 0-65535 (5 + 1 + 5 + 1 + 5 = 17) 2. Prerelease label: Up to 64 characters (not including the `-`) 3. Build metadata: Up to 64 characters (not including the `+`) Total length for these parts: 17 + 1 + 64 + 1 + 64 = 147 It makes you uneasy because we don't like arbitrary limits. But the implications of not having limits on this can really cause harm. A 147-character field will allow for decent indexing.

GiteaMirror commented

2026-02-17 11:07:04 -06:00

@haacked commented on GitHub (May 6, 2013):

Well there's two things that make me uneasy.

The arbitrary limit is due to implementation details about how it's stored. It assumes a varchar variant in a SQL database. Other storage mechanisms might be fine with arbitrary length versions.
I also feel like if anyone creates a version string 147 characters long, they're doing it wrong. Is this really going to be a problem?

It'd make me more comfortable if I saw a precedence for this. Does the OSGI or Debian or any other "versioning" standard impose a size limit on the version?

On the flip side, I can see some idiot uploading a 2MB version string and claiming your not SemVer compliant. ;) I'd say "fuck you" to that person though.

On a lark, I asked @qrush how Ruby Gems stores the version field and it's a varchar 255. If we were to add this to the spec, maybe we just make the length 255 and call it a day as that's the typical default varchar value.

@haacked commented on GitHub (May 6, 2013): Well there's two things that make me uneasy. 1. The arbitrary limit is due to implementation details about how it's stored. It assumes a `varchar` variant in a SQL database. Other storage mechanisms might be fine with arbitrary length versions. 2. I also feel like if anyone creates a version string 147 characters long, they're doing it wrong. Is this really going to be a problem? It'd make me more comfortable if I saw a precedence for this. Does the OSGI or Debian or any other "versioning" standard impose a size limit on the version? On the flip side, I can see some idiot uploading a 2MB version string and claiming your not SemVer compliant. ;) I'd say "fuck you" to that person though. On a lark, I asked @qrush how Ruby Gems stores the version field and it's a `varchar 255`. If we were to add this to the spec, maybe we just make the length 255 and call it a day as that's the typical default varchar value.

GiteaMirror commented

2026-02-17 11:07:04 -06:00

@half-ogre commented on GitHub (May 7, 2013):

I don't think 255 is a bad choice for an arbitrary limit, but this doesn't feel like something that needs to be specified.

I don't recall SemVer ever having a limit on the size of the major, minor, and patch version numbers. Has this been an issue?

It seems just fine to me for systems using SemVer to impose a limit that satisfies their needs. In the case of NuGet, maybe it's 147.

(I'm also not convinced storing the whole version string as text is the best way to index and search on it, but I guess that's not really relevant to this discussion.)

@half-ogre commented on GitHub (May 7, 2013): I don't think 255 is a bad choice for an arbitrary limit, but this doesn't feel like something that needs to be specified. I don't recall SemVer ever having a limit on the size of the major, minor, and patch version numbers. Has this been an issue? It seems just fine to me for systems using SemVer to impose a limit that satisfies their needs. In the case of NuGet, maybe it's 147. (I'm also not convinced storing the whole version string as text is the best way to index and search on it, but I guess that's not really relevant to this discussion.)

GiteaMirror commented

2026-02-17 11:07:05 -06:00

@Tieske commented on GitHub (May 7, 2013):

Add it as a FAQ entry, which basically makes it a recommendation, but at least everyone will be on the same page then (even the 2MB idiot). Something like:

Q: Does semver have a size limit on the version string?
A: The recommended maximum size of a version string is 255 characters. The numerical elements major, minor, patch have a recommended range of 0-65535

Not sure about the addition for numerical elements though.

@Tieske commented on GitHub (May 7, 2013): Add it as a FAQ entry, which basically makes it a recommendation, but at least everyone will be on the same page then (even the 2MB idiot). Something like: > Q: Does semver have a size limit on the version string? > A: The recommended maximum size of a version string is 255 characters. The numerical elements major, minor, patch have a recommended range of 0-65535 Not sure about the addition for numerical elements though.

GiteaMirror commented

2026-02-17 11:07:05 -06:00

@haacked commented on GitHub (May 7, 2013):

@Tieske That's a good idea. If we do anything, I'm leaning towards a FAQ entry. But I'd want to say something like "Don't be an idiot. Keep your versions a reasonable length." :trollface:

Perhaps that's too harsh. 😎

I mean, do we really need to tell people not to have 655536 patches of their package or not to pipe the text of War and Peace (sans spaces and punctuation) into their pre-release tag?

Also, why 65535? Why not 2^32-1 so you can use an unsigned int to store each version part? :trollface:

I agree with @half-ogre. I don't think this spec is the right place for this system restriction. I think it's fine for a system to impose a subset of SemVer.

(I'm also not convinced storing the whole version string as text is the best way to index and search on it, but I guess that's not really relevant to this discussion.)

I think that is relevant to this discussion because the limit assumes the whole thing is stored as a single string. But you might choose to store Major, Minor, and Patch as separate ints for example while storing the pre-release as an arbitrary length string.

In the end, imposing a length feels too much like we're embedding specific implementation details into the spec. My vote is to close this issue and perhaps open a PR that says something like:

Q: Does semver have a size limit on the version string?
A: No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string.

@haacked commented on GitHub (May 7, 2013): @Tieske That's a good idea. If we do anything, I'm leaning towards a FAQ entry. But I'd want to say something like "Don't be an idiot. Keep your versions a reasonable length." :trollface: Perhaps that's too harsh. :sunglasses: I mean, do we _really_ need to tell people not to have 655536 patches of their package or not to pipe the text of War and Peace (sans spaces and punctuation) into their pre-release tag? Also, why `65535`? Why not `2^32-1` so you can use an unsigned int to store each version part? :trollface: I agree with @half-ogre. I don't think this spec is the right place for this system restriction. I think it's fine for a system to impose a subset of SemVer. > (I'm also not convinced storing the whole version string as text is the best way to index and search on it, but I guess that's not really relevant to this discussion.) I think that is relevant to this discussion because the limit assumes the whole thing is stored as a single string. But you might choose to store `Major`, `Minor`, and `Patch` as separate ints for example while storing the pre-release as an arbitrary length string. In the end, imposing a length feels too much like we're embedding specific implementation details into the spec. My vote is to close this issue and perhaps open a PR that says something like: > Q: Does semver have a size limit on the version string? > A: No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string.

GiteaMirror commented

2026-02-17 11:07:06 -06:00

@Tieske commented on GitHub (May 7, 2013):

👍

@Tieske commented on GitHub (May 7, 2013): :+1:

GiteaMirror commented

2026-02-17 11:07:07 -06:00

@jeffhandley commented on GitHub (May 7, 2013):

I'd be good with that.

@jeffhandley commented on GitHub (May 7, 2013): I'd be good with that.

GiteaMirror commented

2026-02-17 11:07:07 -06:00

@half-ogre commented on GitHub (May 7, 2013):

A FAQ answer seems reasonable; although, it also seems reasonable to wait to answer it until it is frequently asked. 😔

@half-ogre commented on GitHub (May 7, 2013): A FAQ answer seems reasonable; although, it also seems reasonable to wait to answer it until it is frequently asked. :pensive:

GiteaMirror commented

2026-02-17 11:07:07 -06:00

@haacked commented on GitHub (May 7, 2013):

Wait, is THAT what FAQ stands for?
😛

@haacked commented on GitHub (May 7, 2013): Wait, is THAT what FAQ stands for? :stuck_out_tongue:

GiteaMirror commented

2026-02-17 11:07:08 -06:00

@jeffhandley commented on GitHub (May 7, 2013):

Ha; okay. We can wait for it to be frequently asked. I have the information I needed though--NuGet can impose its own limitations on length for its own implementation needs.

@jeffhandley commented on GitHub (May 7, 2013): Ha; okay. We can wait for it to be frequently asked. I have the information I needed though--NuGet can impose its own limitations on length for its own implementation needs.

GiteaMirror commented

2026-02-17 11:07:08 -06:00

@Tieske commented on GitHub (May 8, 2013):

If we wait for that to happen, the discussion starts all over again. I'll create a PR with the suggested wording by @Haacked

@Tieske commented on GitHub (May 8, 2013): If we wait for that to happen, the discussion starts all over again. I'll create a PR with the suggested wording by @Haacked

GiteaMirror commented

2026-02-17 11:07:08 -06:00

@Tieske commented on GitHub (May 8, 2013):

ok, I mixed it with #30 😞 sorry about the f#$@ up.

@jeffhandley can you have a look at #30 then they can both be merged as is.

@Tieske commented on GitHub (May 8, 2013): ok, I mixed it with #30 :disappointed: sorry about the f#$@ up. @jeffhandley can you have a look at #30 then they can both be merged as is.

GiteaMirror commented

2026-02-17 11:07:09 -06:00

@jeffhandley commented on GitHub (May 31, 2013):

Thanks for adding that, @Tieske. Looked good.

@jeffhandley commented on GitHub (May 31, 2013): Thanks for adding that, @Tieske. Looked good.

GiteaMirror referenced this issue

2026-02-17 12:17:27 -06:00

[PR #59] [MERGED] Fix typo #719

Sign in to join this conversation.