Build metadata identifier #77
Conversation
Build metadata is a completely optional way to tack on metadata to a version that does not affect the public API or precedence while still be compliant with SemVer. It's not unlike a comment. This allows folks to build on additional meaning or behavior that's meaningful to their custom systems without making any claims about the public version. For example, folks might use it for cache busting, layering custom behavior on top of SemVer, bookkeeping to tie when and where a build was made, etc.
Looks like a big change, but all I did was remove Build metadata from the precedence rules.
The `+` seemed out of character with the rest of the spec. Following the example of the pre-release section, we just spell out "sign" and provide examples for those who don't know what a plus sign is. :)
|
Nitpicking here, but should the following two sentences be identical? pre-release: build metadata: |
|
@EddieGarmon this is a spec. Nitpicking is expected! Yes, they should be identical. The second one is bad grammar. Thanks for catching it! 👍 |
Changed "be comprised of only" with the correct "comprise only". Bonus, it's less verbose.
semver.md
Outdated
There was a problem hiding this comment.
Missing a space between "hyphen" and the regex.
|
Aside from the missing space, this looks really good. Thanks, @haacked! Now... do we want to circle back to freeform metadata and add that in too, as part of RC.2, or do we want to add that in RC.3? I haven't heard back from @loudej for his input on which characters should be allowed. I want to say "any printable, non-space ASCII characters," but I'm not sure how to say that in specific terms and I couldn't find any prior art that defines them. |
|
SemVer defines the meaning of the characters 'a'-'z', 'A'-'Z', '0'-'9', '-', '+', and '.'. Additional metadata starts with the first occurrence of any undefined character, and runs to the end of the version string. The only operation defined for additional metadata is equality. It must be the last component of a semver string, and must be the final component used in comparison. At that point - to be honest - if you remove '+' as a defined character, then the presence of additional metadata would make the formal build number field unnecessary. That is to say |
|
Thanks, @loudej. I do still like the idea of having a character that marks the beginning of the additional metadata, like I feel like we should define a max length for each of these segments though, including the metadata portion, or define an overall max length for the semver string. Maybe 100 characters for the full semver string? |
|
I don't see why a character limit is important; enforcing a max length for the full string seems somewhat contrary to the idea of having completely custom metadata. Maybe a character limit for just the main part and prerelease data, if character limits are necessary for some reason. |
|
For systems storing version numbers as strings in a database, we need to know how big to make the field. We don't want a varchar(max) for version strings. |
|
Wouldn't an optional final flag be useful to indicate the entire string is parsable as a SemVer version. Eg. |
|
Thanks for the input. I'm inclined to leave the changes as-is at this point. We could rathole on this forever. Perhaps we can expand the metadata start sequence in a future version of the spec. But for now, unless anyone sees any glaring issues, I'm going to merge this soon. |
|
I agree that we can leave the freeform metadata off. With the build metadata being meaningless, one could easily just use a segment of the build metadata for whatever extra metadata they want. If there are scenarios that justify the new freeform segment, then a new issue can be filed. Likewise, I'm going to file an issue about the version string length, and we can discuss that there. |
|
String length issue filed as #79 |
|
👍 |
|
This looks good. Can we merge it in? And then do we call this RTM? |
|
Done! |
|
Someone want to send a PR to the github/semver.org repo to update this? I'm kind of busy today. :) |
|
Done: semver/semver.org#58 |
Build metadata is a completely optional way to tack on metadata to a version that does not affect the public API or precedence while still be compliant with SemVer. It's similar to a comment.
This allows folks to build on additional meaning or behavior that's meaningful to their custom systems without making any claims about the public version. For example, folks might use it for cache busting, layering custom behavior on top of SemVer, bookkeeping to tie when and
where a build was made, etc.
This PR is related to #61 and supersedes PR #70. You can see the previous discussions over there.