[GH-ISSUE #463] Breaking change in previous major release #4582

New Issue

GiteaMirror · 2026-06-13T12:50:35-05:00

GiteaMirror commented

2026-06-13 12:50:35 -05:00

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-

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?

GiteaMirror added the duplicate label 2026-06-13 12:50:35 -05:00

GiteaMirror closed this issue

2026-06-13 12:50:38 -05:00

GiteaMirror commented

2026-06-13 12:50:40 -05:00

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

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

GiteaMirror commented

2026-06-13 12:50:41 -05:00

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

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

GiteaMirror commented

2026-06-13 12:50:43 -05:00

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

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

GiteaMirror commented

2026-06-13 12:50:45 -05:00

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

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

GiteaMirror commented

2026-06-13 12:50:46 -05:00

@alexandrtovmach commented on GitHub (Jun 10, 2020):

Closed in favor #395

@alexandrtovmach commented on GitHub (Jun 10, 2020): Closed in favor #395

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4582