[GH-ISSUE #179] Standardize and define acceptable pre release identifiers #6110

New Issue

GiteaMirror · 2026-06-17T04:37:18-05:00

GiteaMirror commented

2026-06-17 04:37:18 -05:00

Originally created by @aaronmallen on GitHub (Feb 12, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/179

Developers are able to place personalized identifiers in the version meta, for example my meta usually is date and commit based X.Y.Z+2014.2.12.4 would be the fourth commit of today. So with this area of personal customization allowed I think it would be a good idea to standardize the pre-release area of semver.

I propose defining what words are acceptable, and what they mean.

just as an example
pre-alpha : development releases and nightly builds
alpha : Software testing phase
beta : feature complete but may have bugs
rc: release canidate
etc...

I think this would be important to indicate to developers quickly what stage of development the software is in. If I look at v1.0.0 which has no pre-release identifiers I am confident in the idea that according to the developer this software is in a release format and ready to rock and roll. If I look at v1.0.0-beta.4 I know that this software is in some form of beta stage without even reading any of the numbers.

The issue is when developers use proprietary terminology in these pre-release identifiers. Having a standard defined as to what is acceptable terminology to use, and what that terminology means will (in my opinion) have a meaningful impact on semver and what it means to developers.

In addition to defining acceptable terminology I would also like to see further documentation on when this pre-release should be incremented. If I see v1.0.0-beta.1 and then later see v1.0.0-beta.2 am I to assume that beta.2 is backwards compatible with beta.1? Without this being defined you run the risk of developers implementing non backwards compatibility features who just assume it is ok to increment the pre-release number instead of the actual version number.

Originally created by @aaronmallen on GitHub (Feb 12, 2014). Original GitHub issue: https://github.com/semver/semver/issues/179 Developers are able to place personalized identifiers in the version meta, for example my meta usually is date and commit based `X.Y.Z+2014.2.12.4` would be the fourth commit of today. So with this area of personal customization allowed I think it would be a good idea to standardize the pre-release area of semver. I propose defining what words are acceptable, and what they mean. _just as an example_ `pre-alpha` : development releases and nightly builds `alpha` : Software testing phase `beta` : feature complete but may have bugs `rc`: release canidate etc... I think this would be important to indicate to developers quickly what stage of development the software is in. If I look at `v1.0.0` which has no pre-release identifiers I am confident in the idea that according to the developer this software is in a release format and ready to rock and roll. If I look at `v1.0.0-beta.4` I know that this software is in some form of beta stage without even reading any of the numbers. The issue is when developers use proprietary terminology in these pre-release identifiers. Having a standard defined as to what is acceptable terminology to use, and what that terminology means will (in my opinion) have a meaningful impact on semver and what it means to developers. In addition to defining acceptable terminology I would also like to see further documentation on when this pre-release should be incremented. If I see `v1.0.0-beta.1` and then later see `v1.0.0-beta.2` am I to assume that `beta.2` is backwards compatible with `beta.1`? Without this being defined you run the risk of developers implementing non backwards compatibility features who just assume it is ok to increment the pre-release number instead of the actual version number.

GiteaMirror closed this issue

2026-06-17 04:37:19 -05:00

GiteaMirror commented

2026-06-17 04:37:19 -05:00

@DoCode commented on GitHub (Feb 12, 2014):

+1

@DoCode commented on GitHub (Feb 12, 2014): +1

GiteaMirror commented

2026-06-17 04:37:20 -05:00

@haacked commented on GitHub (Feb 12, 2014):

We had this discussion in #53 and decided against this.

@haacked commented on GitHub (Feb 12, 2014): We had this discussion in #53 and decided against this.

GiteaMirror commented

2026-06-17 04:37:21 -05:00

@aaronmallen commented on GitHub (Feb 12, 2014):

@Haacked sorry I didn't see that issue. Perhaps maybe just including a point of reference in the documentation pointing developers in the right direction?

@aaronmallen commented on GitHub (Feb 12, 2014): @Haacked sorry I didn't see that issue. Perhaps maybe just including a point of reference in the documentation pointing developers in the right direction?

GiteaMirror commented

2026-06-17 04:37:22 -05:00

@haacked commented on GitHub (Feb 12, 2014):

I think a recommendation of standard terminology could be a separate document perhaps, but it's out of the scope of SemVer.

If I see v1.0.0-beta.1 and then later see v1.0.0-beta.2 am I to assume that beta.2 is backwards compatible with beta.1? Without this being defined you run the risk of developers implementing non backwards compatibility features who just assume it is ok to increment the pre-release number instead of the actual version number.

With pre-release versions, all bets are off about compatibility. That's why it's pre-release. If consumers need a stronger compatibility contract, they can choose to only depend on released software.

@haacked commented on GitHub (Feb 12, 2014): I think a recommendation of standard terminology could be a separate document perhaps, but it's out of the scope of SemVer. > If I see v1.0.0-beta.1 and then later see v1.0.0-beta.2 am I to assume that beta.2 is backwards compatible with beta.1? Without this being defined you run the risk of developers implementing non backwards compatibility features who just assume it is ok to increment the pre-release number instead of the actual version number. With pre-release versions, all bets are off about compatibility. That's why it's pre-release. If consumers need a stronger compatibility contract, they can choose to only depend on released software.

GiteaMirror commented

2026-06-17 04:37:22 -05:00

@aaronmallen commented on GitHub (Feb 12, 2014):

@Haacked my concern isn't with the consumers, I assume most consumers expect stable builds when they download or purchase a product. My concern is with collaborative development, especially in environments like github where John Doe from Switzerland can attempt to interact and contribute to my API. I think it's reasonable to define some standards a bit further then what semver currently offers so John Doe knows exactly what I mean when I say v1.0.0-nightly.2.1.0. It would better the collaborative experience environments like github and bitbucket offer.

@aaronmallen commented on GitHub (Feb 12, 2014): @Haacked my concern isn't with the consumers, I assume most consumers expect stable builds when they download or purchase a product. My concern is with collaborative development, especially in environments like github where John Doe from Switzerland can attempt to interact and contribute to my API. I think it's reasonable to define some standards a bit further then what semver currently offers so John Doe knows exactly what I mean when I say `v1.0.0-nightly.2.1.0`. It would better the collaborative experience environments like github and bitbucket offer.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6110