[GH-ISSUE #111] Does prerelease still imply regular backwards compatibility? #7048

New Issue

GiteaMirror · 2026-06-20T16:41:35-05:00

GiteaMirror commented

2026-06-20 16:41:35 -05:00

Originally created by @TimLovellSmith on GitHub (Jun 11, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/111

One thing I think the semver spec clause 9 could clarify - which compatibility relationships are being talked about for prerelease versions.

I think a prerelease version e.g. 1.2.3-pre isn't necessarily going to be forward compatible with the release of 1.2.3 (depending on what design flaws the prerelease has)

But is a prerelease version 1.2.3-pre required by semver to satisfy the same backwards compatibility with 1.2.2 as 1.2.3 does? (minus bugs)

Originally created by @TimLovellSmith on GitHub (Jun 11, 2013). Original GitHub issue: https://github.com/semver/semver/issues/111 One thing I think the semver spec clause 9 could clarify - which compatibility relationships are being talked about for prerelease versions. I think a prerelease version e.g. 1.2.3-pre isn't necessarily going to be forward compatible with the release of 1.2.3 (depending on what design flaws the prerelease has) But is a prerelease version 1.2.3-pre required by semver to satisfy the same backwards compatibility with 1.2.2 as 1.2.3 does? (minus bugs)

GiteaMirror closed this issue

2026-06-20 16:41:36 -05:00

GiteaMirror commented

2026-06-20 16:41:38 -05:00

@jessewebb commented on GitHub (Jul 30, 2013):

I believe this issue has been addressed with the release of 2.0.0 and may be closed.

Point 9 now includes the sentence:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

I understand this spec to mean that a version 1.2.3-pre may not have the same public API as version 1.2.3 in additive features but it does not mean that it may break the public API established by any prior version. Any backwards incompatible changes must cause the Major version to increase.

Here is a scenario of releases to understand better:

1.0.0 - initial public API release
1.1.0-pre - additive functionality with backward compatibility of 1.0.0
1.1.0 - additive functionality (with possibly different API then 1.1.0-pre) with backward compatibility of 1.0.0
1.1.1-pre - bug fixes with no changes (not even additive) to public API, backwards compatible with 1.1.0
1.1.1 - bug fixes (may not be fixed the same way as in 1.1.1-pre) with no changes (not even additive) to public API, backwards compatible with 1.1.0
2.0.0-pre - may have completely different public API, feature set, and bugs, no backwards compatibility necessary
2.0.0 - may have different API than that of 2.0.0-pre

Hope that helps!

As a side note, if you wish to release a pre-release version which is mostly stable and will likely have the same API as the future, final release, I believe it is good/common practice to use the "rc#" identifier which stands for release candidate. For example:

2.0.0-alpha - likely will undergo API changes before final release
2.0.0-rc1 - attempts to solidify the API, getting ready for the final release
2.0.0-rc2 - may fix some bugs or tweak the API slightly if problems were discovered with RC1
2.0.0 - final release which usually aims to have the exact same or only slightly altered API as former RC

@jessewebb commented on GitHub (Jul 30, 2013): I believe this issue has been addressed with the release of 2.0.0 and may be closed. Point 9 now includes the sentence: > A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. I understand this spec to mean that a version 1.2.3-pre may not have the same public API as version 1.2.3 in additive features but it does not mean that it may break the public API established by any prior version. Any backwards incompatible changes must cause the Major version to increase. Here is a scenario of releases to understand better: 1.0.0 - initial public API release 1.1.0-pre - additive functionality with backward compatibility of 1.0.0 1.1.0 - additive functionality (with possibly different API then 1.1.0-pre) with backward compatibility of 1.0.0 1.1.1-pre - bug fixes with no changes (not even additive) to public API, backwards compatible with 1.1.0 1.1.1 - bug fixes (may not be fixed the same way as in 1.1.1-pre) with no changes (not even additive) to public API, backwards compatible with 1.1.0 2.0.0-pre - may have completely different public API, feature set, and bugs, no backwards compatibility necessary 2.0.0 - may have different API than that of 2.0.0-pre Hope that helps! As a side note, if you wish to release a pre-release version which is mostly stable and will likely have the same API as the future, final release, I believe it is good/common practice to use the "rc#" identifier which stands for release candidate. For example: 2.0.0-alpha - likely will undergo API changes before final release 2.0.0-rc1 - attempts to solidify the API, getting ready for the final release 2.0.0-rc2 - may fix some bugs or tweak the API slightly if problems were discovered with RC1 2.0.0 - final release which usually aims to have the exact same or only slightly altered API as former RC

GiteaMirror commented

2026-06-20 16:41:38 -05:00

@haacked commented on GitHub (Jul 30, 2013):

Great response!

@haacked commented on GitHub (Jul 30, 2013): Great response!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7048