mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #350] Scope of functionality changes between pre-release and next version #4501
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4501
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 @peteroupc on GitHub (Jan 10, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/350
The Semantic Versioning document says:
Because of this, can functionality be added, removed, and/or deprecated between one prerelease version and the next, or between a prerelease version and its normal version, as long as the normal version will comply with Semantic Versioning without regard to the prereleases?
Example: Is it allowed to deprecate functionality and/or add backwards-compatible functionality between version 2.0.0-beta1 and 2.0.0-beta2, even though both would require a minor version change (to, say, 2.1.0)?
@FichteFoll commented on GitHub (Jan 10, 2017):
Yes.
@peteroupc commented on GitHub (Jan 10, 2017):
Thank you for the response, but apparently, I haven't been clear enough. What I intend to ask is:
Is it allowed to make minor-version changes between, say, version 2.0.0-beta1 and 2.0.0-beta2, if the next release will be version 2.0.0 (and not necessarily version 2.1.0)?
@FichteFoll commented on GitHub (Jan 10, 2017):
Again, yes. Prereleases are explicitly excluded from the requirement of increasing minor for new API and major for breaking changes.
Your example is kind of bad because you seem to already be preparing a major release and you are technically allowed to do anything for that, so let's use the following instead.
Say, I have a 1.2.4 release and start working towards 1.2.5. The next "release" I do is a pre-release named 1.2.5-alpha.1, in which I include experimental new API. In 1.2.5-alpha.2 I realize that this API seems pretty useful and intend to include it in the next release, because there are no other important fixes I have to make. So I decide to push the next pre-release to 1.3.0-beta.1 instead of sticking with 1.2.5 and eventually release the actual 1.3.0 version.
All these versions were following the semver standard.
PS: Should I have to release a fix for the 1.2 line after all, I would continue development in 1.2.5-alpha.3, which is based directly on 1.2.4 instead of 1.2.5-alpha.2.
Moral of the story: Don't depend on pre-releases and if you do, absolutely always pin the version you depend on and never accept ranges.
@peteroupc commented on GitHub (Jan 10, 2017):
Thank you again for the answer. This issue is now resolved.