mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #114] recommendations on how to use pre-release #6067
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6067
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 @petermichaux on GitHub (Jun 12, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/114
The pre-release part of the version is free-form. I think it would be beneficial to recommend, with SHOULD clauses (not MUST clauses), that the following are the ones to use
-alpha.1
-alpha.2
-beta.1
-beta.2
-rc.1
-rc.2
@petermichaux commented on GitHub (Jun 13, 2013):
The meaning of these terms should be defined. "alpha" means feature incomplete. "beta" means feature complete. "rc" means this is the code that will be released unless there is a last minute bug found. Perhaps rc and beta are redundant since beta is feature complete.
@isaacs commented on GitHub (Jun 14, 2013):
-1. Since a goal of this spec is to keep it short, I think it'd probably be better to leave these undefined, except to say that they're alphabetically sorted.
@petermichaux commented on GitHub (Jun 14, 2013):
The spec explains how to use major, minor, and patch based on their meaning. I think explain meanings of various pre-releases is just as important so that someone looking at a version with pre-release knows what it means. I don't think this is too long to exclude.
@petermichaux commented on GitHub (Jun 14, 2013):
beta and rc at least differ as follows. A beta version has a feature complete API but may be known to require refactors before being production ready. Perhaps to improve efficiency, for example. A release candidate has those refactors finished.
@Tieske commented on GitHub (Jun 14, 2013):
This has been discussed a number of times, check the closed issues, some times hidden in other issues. None ever made it...
@petermichaux commented on GitHub (Jun 15, 2013):
What are the meanings of "1.0.0--" and "1.0.0-alpha-"? I think the standard would help by providing some guidance.
@isaacs commented on GitHub (Jun 15, 2013):
The SemVer spec is like a dictionary. Its role should be to define a grammar of version strings, but to describe how those version strings are used in practice. The "semantics" come from human beings in the wild.
"1.0.0--" is lower precedence than "1.0.0" or "1.0.0-alpha". It has a prerelease version of "-". Since basically no one ever uses this word in the language of versions, it doesn't need a strict definition. If you see someone using it, you should ask them what they mean by it. Maybe they're using it to tag the first commit in the
1.0branch of their software, and using an intentionally low-valued prerelease tag to indicate that it's "not even alpha" yet. Maybe it's something else entirely.Let's not drift too far towards prescriptivism. People are already dogmatic enough about SemVer, and occasionally use it as a club to complain about one another, and that's not really the point.
The existing semantics in the spec are very close to the general understanding of what version strings are assumed to mean in practice by knowledgeable software developers. There's no need to go any further, imo.
@maxpolk commented on GitHub (Sep 13, 2014):
Semantic Versioning Specification 9, 10, 11 includes treatment of both pre-release and metadata, and sufficiently cover all points raised in this issue, plus, no discussion occurred in over a year, so this issue should be closed
@Tieske commented on GitHub (Sep 14, 2014):
+1 for a close
@haacked commented on GitHub (Sep 14, 2014):
👍
@petermichaux commented on GitHub (Sep 14, 2014):
Where is the discussion in the spec of the meaning of "alpha", "beta", and "rc"?
@maxpolk commented on GitHub (Sep 23, 2015):
As a follow-on comment to this closed issue, it looks like there is no special meaning, and the specification defines pre-release versions as
[0-9A-Za-z-]on purpose. Examples0.3.7andx.7.z.92for pre-release are given to prove that no special permutations exist, andalphahas no more meaning thanaliceorx.7.z.92or anything else. By definition it's random letters and digits, and the only meaning is that it's pre-release of some kind ("...unstable and might not satisfy the intended compatibility requirements...").Some modern software practices may have weekly pre-release versions for two months, and arbitrarily recommending only three "alpha, beta, rc" is inadvisable and inflexible when you require eight or more. I appreciate that that we aren't bound or forced to use a small set of values that already seems to be waning in popularity.