github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 06:53:03 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

[GH-ISSUE #214] What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release) #1876

New Issue
Closed
opened 2026-04-20 09:37:32 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-04-20 09:37:32 -05:00
Owner
Copy Link

Originally created by @euoia on GitHub (Aug 22, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/214

In the interest of being as clear as possible, referring to the following sentence:

What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release)

Consider rewording to use e.g. (for example) instead of i.e. (that is). Or change the sentence to read:

What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a minor release or a patch release)

Originally created by @euoia on GitHub (Aug 22, 2014). Original GitHub issue: https://github.com/semver/semver/issues/214 In the interest of being as clear as possible, referring to the following sentence: > What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a patch release) Consider rewording to use e.g. (for example) instead of i.e. (that is). Or change the sentence to read: > What if I inadvertently alter the public API in a way that is not compliant with the version number change (i.e. the code incorrectly introduces a major breaking change in a minor release or a patch release)
GiteaMirror added the question label 2026-04-20 09:37:32 -05:00
GiteaMirror commented 2026-04-20 09:37:34 -05:00
Author
Owner
Copy Link

@peterjenkins commented on GitHub (Aug 23, 2014):

LGTM. I think I prefer the e.g. version, but both are more correct than what is there now. Thanks!

<!-- gh-comment-id:53137564 --> @peterjenkins commented on GitHub (Aug 23, 2014): LGTM. I think I prefer the e.g. version, but both are more correct than what is there now. Thanks!
GiteaMirror commented 2026-04-20 09:37:34 -05:00
Author
Owner
Copy Link

@euoia commented on GitHub (Aug 27, 2014):

Re-reading that section of the page, there is a similar question above.

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

This question has a different answer (it advises releasing a new minor version, and does not mention considering a major version release). I'm not clear on what the difference between these scenarios is and why they warrant different responses.

Can we clarify the recommendation here and either merge or better distinguish the two questions?

<!-- gh-comment-id:53565860 --> @euoia commented on GitHub (Aug 27, 2014): Re-reading that section of the page, there is a similar question above. > What do I do if I accidentally release a backwards incompatible change as a minor version? This question has a different answer (it advises releasing a new minor version, and does not mention considering a major version release). I'm not clear on what the difference between these scenarios is and why they warrant different responses. Can we clarify the recommendation here and either merge or better distinguish the two questions?
GiteaMirror commented 2026-04-20 09:37:34 -05:00
Author
Owner
Copy Link

@Timoses commented on GitHub (Apr 29, 2018):

I kind of stumbled across this as well.

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

Why would I in this case release a new minor version (as stated in the answer)? I would find it more intuitive to release a patch to "fix" the minor version release.

As for the answer to:

What if I inadvertently alter the public API [...]

A major release with the breaking changes included + a patch release for the broken minor release would sound consistent.

So let's say the history is as follows:
1.0.0 - all good
1.1.0 - oops, released breaking change to API
1.1.1 - fixed the minor version to not break the API
2.0.0 - moved the breaking changes from 1.1.0 into new major release

What do you think?

<!-- gh-comment-id:385258081 --> @Timoses commented on GitHub (Apr 29, 2018): I kind of stumbled across this as well. > What do I do if I accidentally release a backwards incompatible change as a minor version? Why would I in this case release a new minor version (as stated in the answer)? I would find it more intuitive to release a patch to "fix" the minor version release. As for the answer to: > What if I inadvertently alter the public API [...] A major release with the breaking changes included + a patch release for the broken minor release would sound consistent. So let's say the history is as follows: 1.0.0 - all good 1.1.0 - oops, released breaking change to API 1.1.1 - fixed the minor version to not break the API 2.0.0 - moved the breaking changes from 1.1.0 into new major release What do you think?
GiteaMirror commented 2026-04-20 09:37:35 -05:00
Author
Owner
Copy Link

@jwdonahue commented on GitHub (Jan 17, 2020):

@Timoses wrote:

So let's say the history is as follows:
1.0.0 - all good
1.1.0 - oops, released breaking change to API
1.1.1 - fixed the minor version to not break the API
2.0.0 - moved the breaking changes from 1.1.0 into new major release

What do you think?

That seems like a perfectly acceptable solution.

<!-- gh-comment-id:575513559 --> @jwdonahue commented on GitHub (Jan 17, 2020): @Timoses wrote: > So let's say the history is as follows: 1.0.0 - all good 1.1.0 - oops, released breaking change to API 1.1.1 - fixed the minor version to not break the API 2.0.0 - moved the breaking changes from 1.1.0 into new major release > What do you think? That seems like a perfectly acceptable solution.
GiteaMirror commented 2026-04-20 09:37:35 -05:00
Author
Owner
Copy Link

@jwdonahue commented on GitHub (Jan 17, 2020):

@euoia, unless you intend to issue a PR, or have further questions, please close this issue at your earliest possible convenience.

<!-- gh-comment-id:575513718 --> @jwdonahue commented on GitHub (Jan 17, 2020): @euoia, unless you intend to issue a PR, or have further questions, please close this issue at your earliest possible convenience.
GiteaMirror commented 2026-04-20 09:37:36 -05:00
Author
Owner
Copy Link

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

Closed as resolved, thanks everyone for contribution 👍
@euoia If you still have any questions, feel free to re-open

<!-- gh-comment-id:642134364 --> @alexandrtovmach commented on GitHub (Jun 10, 2020): Closed as resolved, thanks everyone for contribution :+1: @euoia If you still have any questions, feel free to re-open
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#1876
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?