mirror of
https://github.com/semver/semver.git
synced 2026-03-11 00:12:22 -05:00
Ambiguity wrt: build and prerelease #16
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#16
Reference in New Issue
Block a user
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?
Originally created by @StoneCypher on GitHub (Apr 9, 2012).
Please define whether prerelease version 1.0.0-example and build version 1.0.0+example are mutually exclusive, and if "no," which must be written first.
@MattiSG commented on GitHub (Apr 25, 2012):
+1
@aes commented on GitHub (Apr 27, 2012):
As I understood it:
1.0.0-example is 1.0.0-example(+nothing) and
1.0.0+example is 1.0.0(-nothing)+example.
The text could perhaps assume less "autism" on the part of the reader
@StoneCypher commented on GitHub (Apr 28, 2012):
Comments like that are inappropriate.
@aes commented on GitHub (Apr 28, 2012):
In what way? I meant that we all tend to be very good at this type of pedantry, so good in fact that you're the first to remark that someone might miss this. It's a good catch and I think that the text should be updated to reflect it.
"Note that a build version MAY be denoted without a pre-release version in which case the dash MUST also be absent."
Or something similar? I thought it was very clear, so I don't really know what would have helped you. Or have I misunderstood? Should it perhaps be something about the order of the components instead?
@StoneCypher commented on GitHub (Apr 28, 2012):
No, the inappropriate remark was the abuse of people with a legitimate mental health issue for your own entertainment.
This isn't difficult to understand.
@StoneCypher commented on GitHub (Apr 28, 2012):
Please go away now. This comment was a technical request for the author, not your private podium to complain.
@aes commented on GitHub (Apr 29, 2012):
I am sincerely very sorry if I touched a sore topic.
The question remains what the document should read to clarify the possibility that the pre-release version might be absent.
A build version MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch version or pre-release version. Notice that build version may be appended even if pre-release version is absent. Identifiers MUST be comprised (...)
@StoneCypher commented on GitHub (Apr 29, 2012):
Oh. You are correct: that clarifies the more important half of my question. I don't know how I overlooked that (maybe it wasn't there?)
Then this boils down to the much less important "please define which one goes first."
Thank you for your help, Anders.
@jlfaber commented on GitHub (Jul 19, 2012):
Prerelease and build are not mutually exclusive. A version string may contain either or both. If both are present, prerelease must appear first, followed by build. (See paragraph 10 "A pre-release version MAY be denoted by appending a dash and a series of dot separated identifiers immediately following the patch version. " and paragraph 11 "A build version MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch version or pre-release version.")
This ordering is necessary since dash is both a valid identifier character and the prerelease separator. If build were allowed to come first, then the following string would be ambiguous: "1.2.3+a-b".
@MattiSG commented on GitHub (Jul 19, 2012):
Indeed. Re-reading it now, I don't understand what felt so ambiguous at the time. The parts @jlfaber highlighted make it quite clear. There’s even an example in paragraph 11: 1.0.0-rc.1+build.1 :-S
Perhaps that example could be given at paragraph 10 instead of in the middle of the long ordering example at paragraph 11?
@StoneCypher commented on GitHub (Jul 19, 2012):
"immediately following the patch version or pre-release version."
If that text was there three months ago, then I overlooked it, and this request is a mistake on my part.
Thank you for the clarification.
@haacked commented on GitHub (Dec 20, 2012):
Sounds like there's nothing to do here then. If you have a suggestion for improved text, do consider submitting a pull request. Thanks!