[GH-ISSUE #284] Version Zero #4448

New Issue

GiteaMirror · 2026-06-13T12:31:19-05:00

GiteaMirror commented

2026-06-13 12:31:19 -05:00

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.

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.

GiteaMirror closed this issue

2026-06-13 12:31:20 -05:00

GiteaMirror commented

2026-06-13 12:31:21 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:31:21 -05:00

@bugmenot2 commented on GitHub (Nov 22, 2015):

rule 1 forbids api changes in version 0

@bugmenot2 commented on GitHub (Nov 22, 2015): rule 1 forbids api changes in version 0

GiteaMirror commented

2026-06-13 12:31:22 -05:00

@FichteFoll commented on GitHub (Nov 22, 2015):

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.

@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.

GiteaMirror commented

2026-06-13 12:31:22 -05:00

@bugmenot2 commented on GitHub (Nov 24, 2015):

rule one is the first thing i've quoted, taken from the top of the doc

@bugmenot2 commented on GitHub (Nov 24, 2015): rule one is the first thing i've quoted, taken from the top of the doc

GiteaMirror commented

2026-06-13 12:31:23 -05:00

@FichteFoll commented on GitHub (Nov 24, 2015):

That is a summary, not a strict rule or specification.

@FichteFoll commented on GitHub (Nov 24, 2015): That is a _summary_, not a strict rule or specification.

GiteaMirror commented

2026-06-13 12:31:24 -05:00

@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

@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

GiteaMirror commented

2026-06-13 12:31:24 -05:00

@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).

@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).

GiteaMirror commented

2026-06-13 12:31:25 -05:00

@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)

@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))

GiteaMirror commented

2026-06-13 12:31:26 -05:00

@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 (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.

GiteaMirror commented

2026-06-13 12:31:26 -05:00

@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.

@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.

GiteaMirror commented

2026-06-13 12:31:27 -05:00

@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.

@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.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4448