[GH-ISSUE #350] Scope of functionality changes between pre-release and next version #1123

New Issue

GiteaMirror · 2026-04-16T10:22:56-05:00

GiteaMirror commented

2026-04-16 10:22:56 -05:00

Originally created by @peteroupc on GitHub (Jan 10, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/350

The Semantic Versioning document says:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

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)?

Originally created by @peteroupc on GitHub (Jan 10, 2017). Original GitHub issue: https://github.com/semver/semver/issues/350 The Semantic Versioning document says: > A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. 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)?

GiteaMirror closed this issue

2026-04-16 10:22:56 -05:00

GiteaMirror commented

2026-04-16 10:22:57 -05:00

@FichteFoll commented on GitHub (Jan 10, 2017):

Yes.

@FichteFoll commented on GitHub (Jan 10, 2017): Yes.

GiteaMirror commented

2026-04-16 10:22:58 -05:00

@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)?

@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)?

GiteaMirror commented

2026-04-16 10:22:58 -05:00

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

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

GiteaMirror commented

2026-04-16 10:22:58 -05:00

@peteroupc commented on GitHub (Jan 10, 2017):

Thank you again for the answer. This issue is now resolved.

@peteroupc commented on GitHub (Jan 10, 2017): Thank you again for the answer. This issue is now resolved.

GiteaMirror referenced this issue

2026-04-16 10:57:35 -05:00

[GH-ISSUE #1123] Migrate to ESM #1547

GiteaMirror referenced this issue

2026-04-20 10:25:12 -05:00

[GH-ISSUE #1123] Migrate to ESM #2414

GiteaMirror referenced this issue