[GH-ISSUE #24] Offending release #884

New Issue

GiteaMirror · 2026-04-16T09:53:56-05:00

GiteaMirror commented

2026-04-16 09:53:56 -05:00

Originally created by @Krilivye on GitHub (May 9, 2012).
Original GitHub issue: https://github.com/semver/semver/issues/24

What do I do if I accidentally release a backwards incompatible change as a minor version?

As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Remember, it is unacceptable to modify versioned releases, even under this circumstance. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version.

I suggest that offending version shall be clearly retaged "offending" inner it's version number like this x.y.z-offending

This would allow automated release tools to alert and/or force upgrade to next legit version.
Same benefit for validation team: No need to test/raise issues on offending version.

Offending version can also break dependencies compatibility.

Offending version breacking backwards compatibility shall be realy marked as NASTY without having to search in documentation/release-notes.

Originally created by @Krilivye on GitHub (May 9, 2012). Original GitHub issue: https://github.com/semver/semver/issues/24 > What do I do if I accidentally release a backwards incompatible change as a minor version? > > As soon as you realize that you've broken the Semantic Versioning spec, fix the problem and release a new minor version that corrects the problem and restores backwards compatibility. Remember, it is unacceptable to modify versioned releases, even under this circumstance. If it's appropriate, document the offending version and inform your users of the problem so that they are aware of the offending version. I suggest that offending version shall be clearly retaged "offending" inner it's version number like this _x.y.z-offending_ This would allow automated release tools to alert and/or force upgrade to next legit version. Same benefit for validation team: No need to test/raise issues on offending version. Offending version can also break dependencies compatibility. Offending version breacking backwards compatibility shall be realy marked as NASTY without having to search in documentation/release-notes.

GiteaMirror closed this issue

2026-04-16 09:53:56 -05:00

GiteaMirror commented

2026-04-16 09:53:57 -05:00

@haacked commented on GitHub (Oct 2, 2012):

Many tools will automatically upgrade if you release a new version with a patch increment or a minor update. The problem with changing the version to "offending" is that once a version is out there, it's out there. You can't really change it in many cases (caching, CDNs, local installs). So it doesn't really help to change the version to include "offending". Simply release a newer version and let your users know.

@haacked commented on GitHub (Oct 2, 2012): Many tools will automatically upgrade if you release a new version with a patch increment or a minor update. The problem with changing the version to "offending" is that once a version is out there, it's out there. You can't really change it in many cases (caching, CDNs, local installs). So it doesn't really help to change the version to include "offending". Simply release a newer version and let your users know.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#884