Build metadata SHOULD be ignored when determining version precedence.
And Section 11 states:
Build metadata does not figure into precedence.
For these statements to have greater consistency, I think Section 10 should state:
Build metadata MUST be ignored when determining version precedence.
Originally created by @toddreed on GitHub (Aug 8, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/150
Section 10 states (emphasis added):
> Build metadata **SHOULD** be ignored when determining version precedence.
And Section 11 states:
> Build metadata **does not** figure into precedence.
For these statements to have greater consistency, I think Section 10 should state:
> Build metadata **MUST** be ignored when determining version precedence.
@toddreed for future reference, if you add "closes #150" Where 150 is the issue number, in your commit message or in the body of the pull request, it'll close the issue automatically when the PR is merged. :)
<!-- gh-comment-id:23036782 -->
@haacked commented on GitHub (Aug 21, 2013):
@toddreed for future reference, if you add "closes #150" Where 150 is the issue number, in your commit message or in the body of the pull request, it'll close the issue automatically when the PR is merged. :)
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 @toddreed on GitHub (Aug 8, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/150
Section 10 states (emphasis added):
And Section 11 states:
For these statements to have greater consistency, I think Section 10 should state:
@haacked commented on GitHub (Aug 8, 2013):
Yeah, I agree. Send a PR?
@pvdb commented on GitHub (Aug 21, 2013):
Does merging #151 mean this ticket can be closed?
@haacked commented on GitHub (Aug 21, 2013):
Yep!
@haacked commented on GitHub (Aug 21, 2013):
@toddreed for future reference, if you add "closes #150" Where 150 is the issue number, in your commit message or in the body of the pull request, it'll close the issue automatically when the PR is merged. :)
@toddreed commented on GitHub (Aug 21, 2013):
@Haacked Ahh—thanks for the tip.