github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 03:53:53 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

[GH-ISSUE #293] Example for build metadata does not comply with the spec itself #1078

New Issue
Open
opened 2026-04-16 10:18:01 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-16 10:18:01 -05:00
Owner
Copy Link

Originally created by @matthijskooijman on GitHub (Feb 20, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/293

Section 10, about build metadata says:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Note that a period is not allowed in the build metadata according to this, but the last example does use periods in the build metadata (exp.sha.5114f85). This makes the section ambigious and confusing: Are periods allowed or not?

Originally created by @matthijskooijman on GitHub (Feb 20, 2016). Original GitHub issue: https://github.com/semver/semver/issues/293 Section 10, about build metadata says: > Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85. Note that a period is _not_ allowed in the build metadata according to this, but the last example does use periods in the build metadata (exp.sha.5114f85). This makes the section ambigious and confusing: Are periods allowed or not?
GiteaMirror added the update label 2026-04-16 10:18:01 -05:00
GiteaMirror commented 2026-04-16 10:18:02 -05:00
Author
Owner
Copy Link

@FichteFoll commented on GitHub (Feb 20, 2016):

https://github.com/mojombo/semver/issues/291 https://github.com/mojombo/semver/issues/249 https://github.com/mojombo/semver/issues/230

<!-- gh-comment-id:186585390 --> @FichteFoll commented on GitHub (Feb 20, 2016): https://github.com/mojombo/semver/issues/291 https://github.com/mojombo/semver/issues/249 https://github.com/mojombo/semver/issues/230
GiteaMirror commented 2026-04-16 10:18:03 -05:00
Author
Owner
Copy Link

@matthijskooijman commented on GitHub (Feb 20, 2016):

Heh, sorry for the noise. Should have read better, apparently. Perhaps the wording could be improved to make this more clear (having four tickets about this suggests that the wording might be improved), though I'm not quite sure what wording would be better. The current wording is pretty concise and accurate. Perhaps change the first sentence to:

Build metadata MAY be denoted by appending a plus sign followed by one or more identifiers. The plus immediately follows the patch or pre-release version and is followed by the first identifier. If multiple identifiers are used, they are separated with dots.

Feel free to ignore this suggestion, but let it at least be my attempt to turn this ticket into something productive after all :-)

<!-- gh-comment-id:186693930 --> @matthijskooijman commented on GitHub (Feb 20, 2016): Heh, sorry for the noise. Should have read better, apparently. Perhaps the wording could be improved to make this more clear (having four tickets about this suggests that the wording might be improved), though I'm not quite sure what wording would be better. The current wording is pretty concise and accurate. Perhaps change the first sentence to: > Build metadata MAY be denoted by appending a plus sign followed by one or more identifiers. The plus immediately follows the patch or pre-release version and is followed by the first identifier. If multiple identifiers are used, they are separated with dots. Feel free to ignore this suggestion, but let it at least be my attempt to turn this ticket into something productive after all :-)
GiteaMirror commented 2026-04-16 10:18:03 -05:00
Author
Owner
Copy Link

@haacked commented on GitHub (Feb 22, 2016):

Mind submitting that suggestion as a pull request?

<!-- gh-comment-id:187255027 --> @haacked commented on GitHub (Feb 22, 2016): Mind submitting that suggestion as a pull request?
GiteaMirror commented 2026-04-16 10:18:04 -05:00
Author
Owner
Copy Link

@matthijskooijman commented on GitHub (Feb 22, 2016):

Willdo. Might not be until next week, though.

<!-- gh-comment-id:187285570 --> @matthijskooijman commented on GitHub (Feb 22, 2016): Willdo. Might not be until next week, though.
GiteaMirror commented 2026-04-16 10:18:05 -05:00
Author
Owner
Copy Link

@matthijskooijman commented on GitHub (Mar 10, 2016):

@Haacked, done!

<!-- gh-comment-id:194828156 --> @matthijskooijman commented on GitHub (Mar 10, 2016): @Haacked, done!
GiteaMirror commented 2026-04-16 10:18:05 -05:00
Author
Owner
Copy Link

@efunkenbusch commented on GitHub (Aug 14, 2018):

I think I had to read the spec 5 times before I stopped skipping over the "dot separated" text. Just something about the way my brain parses the text and ignores what it considers to be fluff makes it not stand out. This, combined with the regex string makes it all too easy to miss. Seems a lot of other peoples brains work the same way.

But yeah, I think the text needs to be stated slightly different as well.

<!-- gh-comment-id:412945085 --> @efunkenbusch commented on GitHub (Aug 14, 2018): I think I had to read the spec 5 times before I stopped skipping over the "dot separated" text. Just something about the way my brain parses the text and ignores what it considers to be fluff makes it not stand out. This, combined with the regex string makes it all too easy to miss. Seems a lot of other peoples brains work the same way. But yeah, I think the text needs to be stated slightly different as well.
GiteaMirror commented 2026-04-16 10:18:07 -05:00
Author
Owner
Copy Link

@alexandrtovmach commented on GitHub (Jun 10, 2020):

Thanks everyone for contributions, you're amazing 🎆 Did you find any consensus?

<!-- gh-comment-id:642141562 --> @alexandrtovmach commented on GitHub (Jun 10, 2020): Thanks everyone for contributions, you're amazing :fireworks: Did you find any consensus?
GiteaMirror commented 2026-04-16 10:18:08 -05:00
Author
Owner
Copy Link

@FichteFoll commented on GitHub (Jun 11, 2020):

The result of this question is #296.

<!-- gh-comment-id:642729390 --> @FichteFoll commented on GitHub (Jun 11, 2020): The result of this question is #296.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label update
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#1078
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?