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
Slightly clarify the build metadata section #296
base: master
Are you sure you want to change the base?
Slightly clarify the build metadata section #296
Conversation
@@ -102,8 +102,10 @@ intended compatibility requirements as denoted by its associated | |||
normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, | |||
1.0.0-x.7.z.92. | |||
|
|||
1. Build metadata MAY be denoted by appending a plus sign and a series of dot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So my concern here is that the language used to define build identifiers was pretty much exactly the same as the language used above to describe pre-releases. Why is it more confusing for build identifiers? Should we change the description of pre-release too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent point. To be honest, I wasn't interested in pre-releases, so I skipped that section when reading the spec. It makes sense to keep them consistent, so I'll update my PR.
Commit added to update the pre-release description as well. If you'd rather have them merged into a single commit, let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Non-breaking, incremental change. Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally find the current version to be easy enough to understand, but the argument that some people had problems with it does indeed seem to indicate unnecessarily complex wording. While the proposed version is more verbose, it should clear such misunderstandings.
(Also note that the previous version should have said "dot-separated" instead of "dot separated".)
Multiple people (semver#291, semver#249, semver#230, semver#293) have missed the fact that the build metadata can contain multiple *dot-separated* identifers, and were confused enough to report a bug about the dots present in one of the examples. This attempts to make it more obvious that multiple identifiers might be used. This closes semver#293.
4a6c3d9
to
19e0e0a
Compare
I rebased this on top of master (there was a minor conflict) and fixed the comment by @FichteFoll (I amended it into the first commit, since I was rebased anyway). |
Closing & re-opening to trigger CI |
Multiple people (#291, #249, #230, #293) have missed the fact that the
build metadata can contain multiple dot-separated identifers, and were
confused enough to report a bug about the dots present in one of the
examples. This attempts to make it more obvious that multiple
identifiers might be used.
This closes #293.