mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #179] Standardize and define acceptable pre release identifiers #986
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#986
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 @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.4would 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 buildsalpha: Software testing phasebeta: feature complete but may have bugsrc: release canidateetc...
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.0which 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 atv1.0.0-beta.4I 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.1and then later seev1.0.0-beta.2am I to assume thatbeta.2is backwards compatible withbeta.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.@DoCode commented on GitHub (Feb 12, 2014):
+1
@haacked commented on GitHub (Feb 12, 2014):
We had this discussion in #53 and decided against this.
@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?
@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.
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.
@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.