don't call the second number a major #411
Conversation
major is always the first number, calling the second a major might be a very confusing. Took me a lot of time to recover from this false belief.
README.md
Outdated
| @@ -299,8 +299,7 @@ Allows changes that do not modify the left-most non-zero element in the | |||
| minor updates for versions `1.0.0` and above, patch updates for | |||
| versions `0.X >=0.1.0`, and *no* updates for versions `0.0.X`. | |||
|
|
|||
| Many authors treat a `0.x` version as if the `x` were the major | |||
| "breaking-change" indicator. | |||
| Many authors treat a `0.x` version as if the `x` were the "major breaking-change" indicator. | |||
There was a problem hiding this comment.
it's not an adjective on "breaking-change" tho, ie, a major breaking change vs a non-major breaking change.
It's precisely as if the x were the semver-major number - that's the intention of the doc.
There was a problem hiding this comment.
that's exactly why I think it should be in "". Because the second digit can't be a major only "major"..kind of major
There was a problem hiding this comment.
In an 0.x version, the second number IS the semver-major number. "major" refers to the breaking change semantic, NOT to the position in the version triple, which in the npm ecosystem depends on if the first and/or second numbers are zero or not.
There was a problem hiding this comment.
could you please refer exactly to the document where it's written ?
There was a problem hiding this comment.
There is no such document; it's the way npm's semver ranges (which it has sole authority over, not the semver spec) has always worked.
A ^ range is "everything non-breaking", and ^0.2.0 does NOT include - and never has included - v0.3.0, because v0.3.0 is semver-major - breaking - compared to v0.2.x.
There was a problem hiding this comment.
Minor and ^ are different things. (See definition of ^ in the readme). ^ works as it's written and it's fine. Does anything work with "minor" in the input or output so we can see it in action by calling some function of the npm?
There was a problem hiding this comment.
from https://github.com/npm/node-semver#caret-ranges-123-025-004 you can see that it's rather "yes". But you don't care about docs anyway (from a parallel discussion). So why would you care about this specific change? As I understand you would rather delete all readme, would you?
There was a problem hiding this comment.
You're putting words in my mouth.
The doc as-is is correct, moving "major" inside the quotes has a different connotation in American English, the language the docs are written in, and that would be an incorrect one.
There was a problem hiding this comment.
No, but I am saying that when docs and implementation disagree, the docs are always wrong.
kokushkin
changed the title
|
It feels like a dead end here... May I ask for a couple of more independent reviews from third parties which are not affiliated by no means with the previous reviewer and who (most importantly!) value the definition over the implementation? |
|
The docs as is accurately describe the nuances with leading zeroes in caret ranges. |
major is always the first number, calling the second a major might be a very confusing. Took me a lot of time to recover from this false belief.
References
raineorshine/npm-check-updates#958