mirror of
https://github.com/semver/semver.git
synced 2026-07-11 03:53:53 -05:00
[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) #7117
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7117
Reference in New Issue
Block a user
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?
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:
Consider rewording to use e.g. (for example) instead of i.e. (that is). Or change the sentence to read:
@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!
@euoia commented on GitHub (Aug 27, 2014):
Re-reading that section of the page, there is a similar question above.
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?
@Timoses commented on GitHub (Apr 29, 2018):
I kind of stumbled across this as well.
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:
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?
@jwdonahue commented on GitHub (Jan 17, 2020):
@Timoses wrote:
That seems like a perfectly acceptable solution.
@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.
@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