[GH-ISSUE #713] should major versions be independent or consecutive #3195

New Issue

GiteaMirror · 2026-04-25T17:31:35-05:00

GiteaMirror commented

2026-04-25 17:31:35 -05:00

Originally created by @Tieske on GitHub (May 28, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/713

consider making another, different, breaking change to an old version, e.g.:

1.0.0 introduces features foo and bar
2.0.0 removes feature foo (only retains bar)

what's the number of a new version based of of 1.0.0, that removes feature bar, and retains foo?

Current "expectations" would probably be that it would become version 3.0.0 since, relative to 2.0.0, we add feature foo, and remove feature bar. OR it is released as a different product/api. (Option A)

The alternate way of doing this would be to consider the major version to be just a unique identifier, and not caring about the number being consecutive. As such it could for example be released as 8.0.0. (Option B)

The main difference is that Option B is more flexible from the publishers perspective, but does not define a natural "latest" version for the "consumer" of the api.

This issue came up when discussing semver/semver#712

So question is: since there is (I think) a natural expectation of major numbers to be consecutive, should the spec be updated to clarify to relation between two major numbers. I'm not proposing what it should be, just asking whether a clarification would make sense.

Edit: added the final question

Originally created by @Tieske on GitHub (May 28, 2021). Original GitHub issue: https://github.com/semver/semver/issues/713 consider making another, different, breaking change to an old version, e.g.: - `1.0.0` introduces features `foo` and `bar` - `2.0.0` removes feature `foo` (only retains `bar`) what's the number of a new version based of of `1.0.0`, that removes feature `bar`, and retains `foo`? Current "expectations" would probably be that it would become version `3.0.0` since, relative to `2.0.0`, we add feature `foo`, and remove feature `bar`. OR it is released as a different product/api. (Option A) The alternate way of doing this would be to consider the `major` version to be just a unique identifier, and not caring about the number being consecutive. As such it could for example be released as `8.0.0`. (Option B) The main difference is that Option B is more flexible from the publishers perspective, but does not define a natural "latest" version for the "consumer" of the api. This issue came up when discussing semver/semver#712 **So question is**: since there is (I think) a natural expectation of major numbers to be consecutive, should the spec be updated to clarify to relation between two major numbers. I'm not proposing what it should be, just asking whether a clarification would make sense. Edit: added the final question

GiteaMirror added the question label 2026-04-25 17:31:35 -05:00

GiteaMirror closed this issue

2026-04-25 17:31:36 -05:00

GiteaMirror commented

2026-04-25 17:31:37 -05:00

@ljharb commented on GitHub (Jun 14, 2021):

@Tieske anything that's not v1 or v2. It could be v3.0.0, or v12345.0.0, but it's not compatible with v1 or v2.

It's irrelevant whether or how it's related to v1 or v2 beyond that it's a breaking change from both.

@ljharb commented on GitHub (Jun 14, 2021): @Tieske anything that's not v1 or v2. It could be v3.0.0, or v12345.0.0, but it's not compatible with v1 or v2. It's irrelevant whether or how it's related to v1 or v2 beyond that it's a breaking change from both.

GiteaMirror commented

2026-04-25 17:31:38 -05:00

@alexandrtovmach commented on GitHub (Jun 14, 2021):

@Tieske is it helpful?

@alexandrtovmach commented on GitHub (Jun 14, 2021): @Tieske is it helpful?

GiteaMirror commented

2026-04-25 17:31:39 -05:00

@Tieske commented on GitHub (Jun 14, 2021):

I clarified the original post by adding a question. I think what @ljharb mentioned is the same as Option B in my post. But should we add a clarification to the spec to make it more explicit?

@Tieske commented on GitHub (Jun 14, 2021): I clarified the original post by adding a question. I think what @ljharb mentioned is the same as Option B in my post. But should we add a clarification to the spec to make it more explicit?

GiteaMirror commented

2026-04-25 17:31:40 -05:00

@alexandrtovmach commented on GitHub (Jun 14, 2021):

I think this changes not required

@alexandrtovmach commented on GitHub (Jun 14, 2021): I think this changes not required

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#3195