I am seeking guidance for the following scenario -
Assume that we have the following multiple production versions of a public API -
1.1.0
2.1.2
If a bug/defect was identified in the "1.1.0" version fixing which would introduce a breaking non-backward compatible change, how would the versioning need to be handled? Following semver, a breaking change would necessitate incrementing the major version - so "1.1.0" should become "2.0.0". However, we already have the next major version "2.1.2" live with its own changes.
Is it advisable to-
Skip numbers between major version upgrades to accomodate for such scenarios? i.e. the next planned major version after "1.0.0" should be "3.0.0"?
Any other suggestions?
Originally created by @rsingh74 on GitHub (Sep 28, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/463
I am seeking guidance for the following scenario -
Assume that we have the following multiple production versions of a public API -
1.1.0
2.1.2
If a bug/defect was identified in the "1.1.0" version fixing which would introduce a breaking non-backward compatible change, how would the versioning need to be handled? Following semver, a breaking change would necessitate incrementing the major version - so "1.1.0" should become "2.0.0". However, we already have the next major version "2.1.2" live with its own changes.
Is it advisable to-
1. Skip numbers between major version upgrades to accomodate for such scenarios? i.e. the next planned major version after "1.0.0" should be "3.0.0"?
2. Any other suggestions?
@rsingh74, is this your StackOverflow question? Either way, that really is the best forum for this kind of Q&A.
The real problem with this scenario is that you just can't predict how many bugs you might find that require breaking changes to fix them. Where do you draw the line? Should you skip two, three or a hundred major versions to leave room for breaking bugs in the v1.0.0? Simply rename your product from X 1.y.z to X.Classic 2.0.0 with the breaking fix in it, and your good.
Unless you have further questions, please close this thread at your earliest possible convenience. We're trying to limit open issues to actionable items that have some chance of leading to a PR.
<!-- gh-comment-id:427625117 -->
@jwdonahue commented on GitHub (Oct 7, 2018):
@rsingh74, is this your [StackOverflow question](@rsingh74)? Either way, that really is the best forum for this kind of Q&A.
The real problem with this scenario is that you just can't predict how many bugs you might find that require breaking changes to fix them. Where do you draw the line? Should you skip two, three or a hundred major versions to leave room for breaking bugs in the v1.0.0? Simply rename your product from X 1.y.z to X.Classic 2.0.0 with the breaking fix in it, and your good.
Unless you have further questions, please close this thread at your earliest possible convenience. We're trying to limit open issues to actionable items that have some chance of leading to a PR.
Anyone can link to the previous discussion on this as it interests me? I've been searching but cannot find it. I remember someone describing another way of solving this.
<!-- gh-comment-id:448011884 -->
@athkalia commented on GitHub (Dec 17, 2018):
Anyone can link to the previous discussion on this as it interests me? I've been searching but cannot find it. I remember someone describing another way of solving this.
@rsingh74, unless you intend to issue a PR or have further questions on this topic, please close this thread at your earliest possible convenience.
<!-- gh-comment-id:522171312 -->
@jwdonahue commented on GitHub (Aug 16, 2019):
@rsingh74, unless you intend to issue a PR or have further questions on this topic, please close this thread at your earliest possible convenience.
@jeme @athkalia Do you mean #395? The issue seems to be related if not a duplicate of it.
<!-- gh-comment-id:531289011 -->
@claell commented on GitHub (Sep 13, 2019):
@jeme @athkalia Do you mean #395? The issue seems to be related if not a duplicate of it.
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 @rsingh74 on GitHub (Sep 28, 2018).
Original GitHub issue: https://github.com/semver/semver/issues/463
I am seeking guidance for the following scenario -
Assume that we have the following multiple production versions of a public API -
1.1.0
2.1.2
If a bug/defect was identified in the "1.1.0" version fixing which would introduce a breaking non-backward compatible change, how would the versioning need to be handled? Following semver, a breaking change would necessitate incrementing the major version - so "1.1.0" should become "2.0.0". However, we already have the next major version "2.1.2" live with its own changes.
Is it advisable to-
@jwdonahue commented on GitHub (Oct 7, 2018):
@rsingh74, is this your StackOverflow question? Either way, that really is the best forum for this kind of Q&A.
The real problem with this scenario is that you just can't predict how many bugs you might find that require breaking changes to fix them. Where do you draw the line? Should you skip two, three or a hundred major versions to leave room for breaking bugs in the v1.0.0? Simply rename your product from X 1.y.z to X.Classic 2.0.0 with the breaking fix in it, and your good.
Unless you have further questions, please close this thread at your earliest possible convenience. We're trying to limit open issues to actionable items that have some chance of leading to a PR.
@athkalia commented on GitHub (Dec 17, 2018):
Anyone can link to the previous discussion on this as it interests me? I've been searching but cannot find it. I remember someone describing another way of solving this.
@jwdonahue commented on GitHub (Aug 16, 2019):
@rsingh74, unless you intend to issue a PR or have further questions on this topic, please close this thread at your earliest possible convenience.
@claell commented on GitHub (Sep 13, 2019):
@jeme @athkalia Do you mean #395? The issue seems to be related if not a duplicate of it.
@alexandrtovmach commented on GitHub (Jun 10, 2020):
Closed in favor #395