-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Precendence between 1.0.0 and 1.0.1-alpha #690
Comments
Yes, if you consider prereleases in ranges. https://npmjs.com/node-semver, for example, doesn't include prereleases by default in a number of its range APIs. |
I just got 404 from the link in your comments. And could provide more detail evidence of the 'yes' answer? |
whoops, sorry, https://npmjs.com/semver By default, prereleases aren't included, so the range wouldn't include the prerelease. |
Thanks ljharb. From the page I aware the ">1.0.0" wouldn't include the "1.0.1-alpha". Following description is copied from that page,
|
@wbzhang2594 is it helpful? |
Apply the rules specified by #11 in the spec: Major 1 equals Major 1 You're done, 1.0.0 is less than 1.0.1-anything. But precedence rules only specify the sort order. They do not specify every relevant policy. Given a version history of just: 1.0.0 Most tools will not automatically update you to 1.0.1-alpha from 1.0.0, unless you specify that you are willing to take prereleases. Most tools don't actually understand a version range of (1.0.0, 1.5.0-alpha] for instance. Their range notations are ad-hoc and often incomplete. But then, most policies fall into either production or development camps, with different goals in mind. Production has no interest in prereleases and development generally won't allow automatic updates from any version to the next, whether it's prerelease or not. Production wants to take bug fixes automatically, developers want to avoid the unscheduled work that would be involved with automatic updates to prerelease bits. The later is due to the fact that any change in a prerelease version is potentially a breaking change. So they might take automatic updates of release version, but they want only manual updates of prerelease bits. The SemVer spec is mute on the topic of ranges for good reasons. Handling ranges properly is very hard to get right and requires non-trivial code. The original spec author wanted to avoid limiting adoption due to over-engineering the specification. They simply specified a sort order, without saying anything at all about selection policies. This is a common thread throughout the spec. It leaves many things unstated, while constraining only what must be constrained for the purpose of defining the semantics of the scheme. |
#584 will make it unmute on ranges. |
Yes I know that is in the works. I think it is an interesting exercise. I also believe it doesn't belong in the SemVer spec. Better to establish standard minimal documentation practices that each of the various SemVer conforming tool owners should adhere to, than to establish any range notation scheme, however watered down to fit the common denominators. The SemVer 2.0.0 semantics and syntax are the most common denominator among the available tools. When a handful of those tools have completely defined their particular scheme in terms of an internationally understood range/interval notation, it wouldn't hurt for them to identify and try to migrate to a common, constantly growing set of range notations. I would hope however, that after the exercise of defining their notations using standard math, they might be motivated to support those standard notations directly in their respective tools. I think that it should reside in a separate spec. though, independent of SemVer and it's format. |
I'm a little obsessive to ask this question. As there isn't an example of it.
In my understanding, "1.0.1-alpha < 1.0.1" and "1.0.0 < 1.0.1".
But is this true of "1.0.0 < 1.0.1-alpha" ?
The text was updated successfully, but these errors were encountered: