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).
Original GitHub issue: https://github.com/semver/semver/issues/79
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.
Ugh. Got a proposed max length? I can't put a finger on why this makes me uneasy.
<!-- gh-comment-id:17509996 -->
@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.
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.
<!-- gh-comment-id:17511915 -->
@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.
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.
<!-- gh-comment-id:17514239 -->
@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.
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.)
<!-- gh-comment-id:17515971 -->
@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.)
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.
<!-- gh-comment-id:17523887 -->
@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 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.
<!-- gh-comment-id:17553676 -->
@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.
A FAQ answer seems reasonable; although, it also seems reasonable to wait to answer it until it is frequently asked. 😔
<!-- gh-comment-id:17567257 -->
@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:
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.
<!-- gh-comment-id:17571959 -->
@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.
If we wait for that to happen, the discussion starts all over again. I'll create a PR with the suggested wording by @Haacked
<!-- gh-comment-id:17591667 -->
@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
@jeffhandley can you have a look at #30 then they can both be merged as is.
<!-- gh-comment-id:17591997 -->
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @jeffhandley on GitHub (Mar 15, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/79
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.
@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.
@jeffhandley commented on GitHub (May 6, 2013):
Here's my recommendation:
-)+)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.
@haacked commented on GitHub (May 6, 2013):
Well there's two things that make me uneasy.
varcharvariant in a SQL database. Other storage mechanisms might be fine with arbitrary length versions.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.@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.)
@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:
Not sure about the addition for numerical elements though.
@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 not2^32-1so 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 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, andPatchas 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:
@Tieske commented on GitHub (May 7, 2013):
👍
@jeffhandley commented on GitHub (May 7, 2013):
I'd be good with that.
@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. 😔
@haacked commented on GitHub (May 7, 2013):
Wait, is THAT what FAQ stands for?
😛
@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.
@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):
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.
@jeffhandley commented on GitHub (May 31, 2013):
Thanks for adding that, @Tieske. Looked good.