increment the:
1. MAJOR version when you make incompatible API changes,
conflicts with
Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.
Version zero "MUST" be an exception to the 1st rule.
Originally created by @bugmenot2 on GitHub (Nov 21, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/284
Am I the only one who sees this?
```
increment the:
1. MAJOR version when you make incompatible API changes,
```
conflicts with
```
Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.
```
Version zero "MUST" be an exception to the 1st rule.
I think there is no conflict. There is also a text:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
<!-- gh-comment-id:158688929 -->
@bessarabov commented on GitHub (Nov 21, 2015):
I think there is no conflict. There is also a text:
> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Please quote this rule 1 of yours. The one I'm seeing reads
Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
and rule 8 reads
Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
<!-- gh-comment-id:158759912 -->
@FichteFoll commented on GitHub (Nov 22, 2015):
Please quote this rule 1 of yours. The one I'm seeing reads
> 1. Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
and rule 8 reads
> 8) Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.
i think the exception shoud be included in the summary, referenced to, or at least hinted to with a word guard. this spec is for programmers
<!-- gh-comment-id:159393572 -->
@bugmenot2 commented on GitHub (Nov 24, 2015):
i think the exception shoud be included in the summary, referenced to, or at least hinted to with a word guard. this spec is for programmers
This is confusing. I think the terms backward-compatible and backward-incompatible changes should be defined clearly (https://github.com/mojombo/semver/issues/256). For instance, if a dependency changes it's API and you refactor your code to reflect those changes (e.g. remove/substitute deprecated attributes), your code now becomes "backwards-incompatible" as it can no longer use those attributes. Is it then reasonable to bump a major release version for every minor bug fix caused by your dependencies? How does semver handle propagation or incompatibility from dependencies?
<!-- gh-comment-id:161848485 -->
@pylang commented on GitHub (Dec 4, 2015):
This is confusing. I think the terms _backward-compatible_ and _backward-incompatible changes_ should be defined clearly (https://github.com/mojombo/semver/issues/256). For instance, if a dependency changes it's API and you refactor your code to reflect those changes (e.g. remove/substitute deprecated attributes), your code now becomes "backwards-incompatible" as it can no longer use those attributes. Is it then reasonable to bump a major release version for every minor bug fix caused by your dependencies? How does semver handle propagation or incompatibility from dependencies?
Reticence to bump major versions has been mentioned elsewhere (https://github.com/mojombo/semver/issues/260).
FYI see also #221 for discussion of whether the "Magic Zero" exception rules are actually beneficial, and whether they should be dropped. (I'm in the camp that they should be dropped, as per my comment in that thread)
<!-- gh-comment-id:165109906 -->
@ronen commented on GitHub (Dec 16, 2015):
FYI see also #221 for discussion of whether the "Magic Zero" exception rules are actually beneficial, and whether they should be dropped. (I'm in the camp that they should be dropped, as per [my comment in that thread](https://github.com/mojombo/semver/issues/221#issuecomment-64409450))
@ronen, I am all-in for dropping the magic zero loop-hole.
@bugmenot2, I agree that the language in the summary is mildly in conflict with the spec, but it's the numbered paragraphs that comprise the actual spec.
<!-- gh-comment-id:350423215 -->
@jwdonahue commented on GitHub (Dec 9, 2017):
@ronen, I am all-in for dropping the magic zero loop-hole.
@bugmenot2, I agree that the language in the summary is mildly in conflict with the spec, but it's the numbered paragraphs that comprise the actual spec.
@bugmenot2, unless you have further questions/comments or intend to issue PR, please close this issue at your earliest possible convenience.
<!-- gh-comment-id:427918563 -->
@jwdonahue commented on GitHub (Oct 8, 2018):
@bugmenot2, unless you have further questions/comments or intend to issue PR, please close this issue at your earliest possible convenience.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
@bugmenot2 Thanks for report. Closing as inactive, if there are still any questions, feel free to re-open.
<!-- gh-comment-id:642088274 -->
@alexandrtovmach commented on GitHub (Jun 10, 2020):
@bugmenot2 Thanks for report. Closing as inactive, if there are still any questions, feel free to re-open.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @bugmenot2 on GitHub (Nov 21, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/284
Am I the only one who sees this?
conflicts with
Version zero "MUST" be an exception to the 1st rule.
@bessarabov commented on GitHub (Nov 21, 2015):
I think there is no conflict. There is also a text:
@bugmenot2 commented on GitHub (Nov 22, 2015):
rule 1 forbids api changes in version 0
@FichteFoll commented on GitHub (Nov 22, 2015):
Please quote this rule 1 of yours. The one I'm seeing reads
and rule 8 reads
@bugmenot2 commented on GitHub (Nov 24, 2015):
rule one is the first thing i've quoted, taken from the top of the doc
@FichteFoll commented on GitHub (Nov 24, 2015):
That is a summary, not a strict rule or specification.
@bugmenot2 commented on GitHub (Nov 24, 2015):
i think the exception shoud be included in the summary, referenced to, or at least hinted to with a word guard. this spec is for programmers
@pylang commented on GitHub (Dec 4, 2015):
This is confusing. I think the terms backward-compatible and backward-incompatible changes should be defined clearly (https://github.com/mojombo/semver/issues/256). For instance, if a dependency changes it's API and you refactor your code to reflect those changes (e.g. remove/substitute deprecated attributes), your code now becomes "backwards-incompatible" as it can no longer use those attributes. Is it then reasonable to bump a major release version for every minor bug fix caused by your dependencies? How does semver handle propagation or incompatibility from dependencies?
Reticence to bump major versions has been mentioned elsewhere (https://github.com/mojombo/semver/issues/260).
@ronen commented on GitHub (Dec 16, 2015):
FYI see also #221 for discussion of whether the "Magic Zero" exception rules are actually beneficial, and whether they should be dropped. (I'm in the camp that they should be dropped, as per my comment in that thread)
@jwdonahue commented on GitHub (Dec 9, 2017):
@ronen, I am all-in for dropping the magic zero loop-hole.
@bugmenot2, I agree that the language in the summary is mildly in conflict with the spec, but it's the numbered paragraphs that comprise the actual spec.
@jwdonahue commented on GitHub (Oct 8, 2018):
@bugmenot2, unless you have further questions/comments or intend to issue PR, please close this issue at your earliest possible convenience.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
@bugmenot2 Thanks for report. Closing as inactive, if there are still any questions, feel free to re-open.