[GH-ISSUE #297] When is a version backwards compatible with another version? #2929

New Issue

GiteaMirror · 2026-04-25T17:03:55-05:00

GiteaMirror commented

2026-04-25 17:03:55 -05:00

Originally created by @Virtlink on GitHub (Mar 14, 2016).
Original GitHub issue: https://github.com/semver/semver/issues/297

I believe SemVer is not just to allow humans to interpret version numbers, but also for computers to be able to determine version compatibility. So I think the answer to this question should be part of the specification:

When is a version backwards compatible with another version?

From what I can gather, given two versions A and B, where A < B, B is backward compatible with (and can be used in place of) A iff:

The major version number of B is equal to the major version number of A.
The major version number is not 0 (as that may introduce breaking changes).
The minor and patch version numbers of B are greater than or equal to those of A.
Both A and B are not pre-release versions (as they may introduce breaking changes).

Please correct me if I'm wrong.

Originally created by @Virtlink on GitHub (Mar 14, 2016). Original GitHub issue: https://github.com/semver/semver/issues/297 I believe SemVer is not just to allow humans to interpret version numbers, but also for computers to be able to determine version compatibility. So I think the answer to this question should be part of the specification: **When is a version backwards compatible with another version?** From what I can gather, given two versions A and B, where A < B, B is backward compatible with (and can be used in place of) A iff: - The major version number of B is equal to the major version number of A. - The major version number is not 0 (as that may introduce breaking changes). - The minor and patch version numbers of B are greater than or equal to those of A. - Both A and B are not pre-release versions (as they may introduce breaking changes). Please correct me if I'm wrong.

GiteaMirror closed this issue

2026-04-25 17:03:55 -05:00

GiteaMirror commented

2026-04-25 17:03:56 -05:00

@FichteFoll commented on GitHub (Mar 14, 2016):

Looks correct.

And yes, semver is also for computers.

@FichteFoll commented on GitHub (Mar 14, 2016): Looks correct. And yes, semver is also for computers.

GiteaMirror commented

2026-04-25 17:03:56 -05:00

@islandsvinur commented on GitHub (Dec 20, 2017):

I cannot seem to find a definitive answer in the spec on this, but it seems that it is highly depending on how bugfixes are cascaded onto higher minor versions:

Suppose I have a dependency on a library with version 1.1.2, and 1.2.5 just came out. Can I safely upgrade if I previously upgraded to 1.1.2 because of the bugfix it delivered. There is no guarantee in the SemVer spec that 1.2.5 should contain the bugfix of 1.1.2. Consider the following timeline: 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.1.2 (from maintenance branch), 1.2.2.

1.1.2 was released after the release of 1.2.0, so for the bugfix to be included in the 1.2 line there must have been an effort to get it in, and even if it got in, we cannot know in which release that was. In the example, the bug still exists in 1.2.1 and might be fixed in 1.2.2.

Therefore, 1.2.2 is not compatible with 1.1.2 (even though SemVer says it is).

@islandsvinur commented on GitHub (Dec 20, 2017): I cannot seem to find a definitive answer in the spec on this, but it seems that it is highly depending on how bugfixes are cascaded onto higher minor versions: Suppose I have a dependency on a library with version 1.1.2, and 1.2.5 just came out. Can I safely upgrade if I previously upgraded to 1.1.2 *because of the bugfix it delivered*. There is no guarantee in the SemVer spec that 1.2.5 should contain the bugfix of 1.1.2. Consider the following timeline: 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.1.2 (from maintenance branch), 1.2.2. 1.1.2 was released *after* the release of 1.2.0, so for the bugfix to be included in the 1.2 line there must have been an effort to get it in, and even if it got in, we cannot know in which release that was. In the example, the bug still exists in 1.2.1 and might be fixed in 1.2.2. Therefore, 1.2.2 is *not* compatible with 1.1.2 (even though SemVer says it is).

GiteaMirror commented

2026-04-25 17:03:56 -05:00

@FichteFoll commented on GitHub (Dec 21, 2017):

Sounds like you're considering the bugfix as a breaking change. That's not what semver defines, though, since breaking changes are supposed to increase the major version number.
It might seem like you are depending on buggy behavior.

@FichteFoll commented on GitHub (Dec 21, 2017): Sounds like you're considering the bugfix as a breaking change. That's not what semver defines, though, since breaking changes are supposed to increase the major version number. It might seem like you are depending on buggy behavior.

GiteaMirror commented

2026-04-25 17:03:56 -05:00

@haacked commented on GitHub (Dec 26, 2017):

I believe the original question was answered. I'll close this for now and feel free to comment if there's more to do.

@haacked commented on GitHub (Dec 26, 2017): I believe the original question was answered. I'll close this for now and feel free to comment if there's more to do.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2929