mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[Question] Semver rules for pre-release #441
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#441
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 @Moser-ss on GitHub (Oct 26, 2020).
Hey, I have a great question.
This rule
>=1.2.3should match the version4.5.6-rc.1?Or this rule is only to indicate to I want stable releases?
Because 4.5.6-rc.1 is greater than 1.2.3
@klehelley commented on GitHub (Oct 26, 2020):
Provided the rule you wrote means "higher or equal to
1.2.3according to the SemVer precedence rules", then version4.5.3-rc.1matches.The way you have worded your question it feels like you are not asking about SemVer "by itself", but in relation to the way it is used by some tools. Am I right to think that? Because if that is the case, you want to ask the tool maintainers what this notation means.
@steveklabnik commented on GitHub (Oct 28, 2020):
Currently, the semver spec does not speak about this at all, so strictly, the answer is unknown.
https://github.com/semver/semver/pull/584 is a proposal to define this behavior. In general, this would not match, because pre-releases only match when a pre-release is requested, though I still have not had time to truly review the proposal and so don't know if it says this or not.
@Stargateur commented on GitHub (May 11, 2022):
@steveklabnik semver clearly give two examples:
I think semver crate of Rust is totally wrong about this. Also I don't see why pre-release should be exclude of this, precedence rules are not about compatibility rules.
^~should clearly exclude pre-release but>=><=<=should not cause these operator are for ordering so they should use precedence rules.