recommendations on how to use pre-release #77

New Issue

2026-02-17T11:09:29-06:00

GiteaMirror commented

2026-02-17 11:09:29 -06:00

Originally created by @petermichaux on GitHub (Jun 12, 2013).

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

Originally created by @petermichaux on GitHub (Jun 12, 2013). 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

GiteaMirror closed this issue

2026-02-17 11:09:29 -06:00

GiteaMirror commented

2026-02-17 11:09:30 -06:00

@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.

@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.

GiteaMirror commented

2026-02-17 11:09:31 -06:00

@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.

@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.

GiteaMirror commented

2026-02-17 11:09:31 -06:00

@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): 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.

GiteaMirror commented

2026-02-17 11:09:32 -06:00

@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.

@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.

GiteaMirror commented

2026-02-17 11:09:33 -06:00

@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...

@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...

GiteaMirror commented

2026-02-17 11:09:33 -06:00

@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.

@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.

GiteaMirror commented

2026-02-17 11:09:34 -06:00

@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.0 branch 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.

@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.0` branch 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.

GiteaMirror commented

2026-02-17 11:09:34 -06:00

@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

@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

GiteaMirror commented

2026-02-17 11:09:35 -06:00

@Tieske commented on GitHub (Sep 14, 2014):

+1 for a close

@Tieske commented on GitHub (Sep 14, 2014): +1 for a close

GiteaMirror commented

2026-02-17 11:09:36 -06:00

@haacked commented on GitHub (Sep 14, 2014):

👍

@haacked commented on GitHub (Sep 14, 2014): :+1:

GiteaMirror commented

2026-02-17 11:09:36 -06:00

@petermichaux commented on GitHub (Sep 14, 2014):

Where is the discussion in the spec of the meaning of "alpha", "beta", and "rc"?

@petermichaux commented on GitHub (Sep 14, 2014): Where is the discussion in the spec of the _meaning_ of "alpha", "beta", and "rc"?

GiteaMirror commented

2026-02-17 11:09:37 -06:00

@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. Examples 0.3.7 and x.7.z.92 for pre-release are given to prove that no special permutations exist, and alpha has no more meaning than alice or x.7.z.92 or 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.

@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. Examples `0.3.7` and `x.7.z.92` for pre-release are given to prove that no special permutations exist, and `alpha` has no more meaning than `alice` or `x.7.z.92` or 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.