mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[GH-ISSUE #802] Can you modify versioned prereleases? #2261
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#2261
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 @CidTori on GitHub (Feb 13, 2022).
Original GitHub issue: https://github.com/semver/semver/issues/802
The FAQ states that "it is unacceptable to modify versioned releases", but is it acceptable to modify versioned pre-releases?
For example, can you reuse version 1.2.3-alpha (or 1.2.3-SNAPSHOT) until it's stable enough, or do you need to increment it (1.2.3-alpha.1, 1.2.3-alpha.2, …) each time you make a change?
If both are acceptable, are their best practices (like maybe you can reuse alphas but not betas or rcs since they're public)?
@ljharb commented on GitHub (Feb 13, 2022):
Prereleases are themselves still releases, so no.
@CidTori commented on GitHub (Feb 13, 2022):
Does it mean that Maven's SNAPSHOTs aren't SemVer compliant?
@ljharb commented on GitHub (Feb 13, 2022):
I don’t know anything about maven; but to be compliant, a released version number can’t ever change.
@CidTori commented on GitHub (Feb 13, 2022):
When a Maven artifact version ends with "SNAPSHOT", you don't need to use a version range in your dependencies : Maven will always use the latest build of that version.
Typically, you have one pre-release version (for example 1.2.3-SNAPSHOT), and each time you make a change, you reuse that version, and users of your artifact will use it.
Then, when you are ready to release, you simply strip the "-SNAPSHOT" from your current version (for example, 1.2.3), and this one won't be changed.
Version ranges are rarely used with Maven, since there are no dependencies version pinning file (like package-lock.json for npm).
@ljharb commented on GitHub (Feb 13, 2022):
That indeed does not sound semver-compliant to me.
@Saklad5 commented on GitHub (Feb 15, 2022):
If you want something to be subject to change, simply avoid giving it a version in the first place. This is why versions are generally represented as tags in Git: they are permanently assigned to a specific commit.
In light of this, by the way, I actually recommend against referencing the current version in anything under source control: any commit that doesn’t update it would violate SemVer.
Swift Package Manager has an approach I’m quite fond of: if users want to specify dependencies that can change like that, they use a Git branch instead of a semantic version. If a package actually does this, other packages can’t depend on specific versions of it: that means you don’t have to worry about a dependency doing it.
@ljharb commented on GitHub (Feb 15, 2022):
That depends on your ecosystem; in most, git is for development, not consumption, so the only versions that matter are the published ones.
@jwdonahue commented on GitHub (Mar 8, 2023):
That is difficult to enforce. Git tags should generally be considered malleable. Tagging commits with version numbers does not scale well. Versioning should be done on the backend of the build.
@steveklabnik commented on GitHub (Mar 9, 2023):
In general, semver's perspective is that releases are immutable.