[GH-ISSUE #510] what if a change is potentially backward incompatible #4622

New Issue

GiteaMirror · 2026-06-13T12:53:49-05:00

GiteaMirror commented

2026-06-13 12:53:49 -05:00

Originally created by @ghost on GitHub (Apr 10, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/510

Under all intended/expected usages of my API the change will not be backwards incompatible, but it's possible people were using it in an unexpected way and that makes this change backwards incompatible.

The specific change I will make is adding my own equals and hashCode methods onto a java class, which is much more sensible than the default (and probably what people were doing anyway if they were trying to compare instances of the class). But there may be a really small chance that a project depending on my API was using object.equals in the old way (I can't think of why they would do that, it's a possibility), which would cause this change to be breaking.

I personally don't feel this change warrants a major version number increment, I am inclined to change the minor version, even though it's technically backward incompatible.

Originally created by @ghost on GitHub (Apr 10, 2019). Original GitHub issue: https://github.com/semver/semver/issues/510 Under all intended/expected usages of my API the change will not be backwards incompatible, but it's possible people were using it in an unexpected way and that makes this change backwards incompatible. The specific change I will make is adding my own `equals` and `hashCode` methods onto a java class, which is much more sensible than the default (and probably what people were doing anyway if they were trying to compare instances of the class). But there may be a really small chance that a project depending on my API was using object.equals in the old way (I can't think of why they would do that, it's a possibility), which would cause this change to be breaking. I personally don't feel this change warrants a major version number increment, I am inclined to change the minor version, even though it's technically backward incompatible.

GiteaMirror added the question label 2026-06-13 12:53:49 -05:00

GiteaMirror closed this issue

2026-06-13 12:53:50 -05:00

GiteaMirror commented

2026-06-13 12:53:51 -05:00

@ljharb commented on GitHub (Apr 10, 2019):

Better to err on the side of caution. A major doesn’t cost you anything, but a breaking minor can cost your users a lot.

@ljharb commented on GitHub (Apr 10, 2019): Better to err on the side of caution. A major doesn’t cost you anything, but a breaking minor can cost your users a lot.

GiteaMirror commented

2026-06-13 12:53:51 -05:00

@ghost commented on GitHub (Apr 10, 2019):

@ljharb that's what I ended up going with, but i grouped it with some other changes too that made it feel worth while.

@ghost commented on GitHub (Apr 10, 2019): @ljharb that's what I ended up going with, but i grouped it with some other changes too that made it feel worth while.

GiteaMirror commented

2026-06-13 12:53:51 -05:00

@grv87 commented on GitHub (May 17, 2019):

Key question: do you think unexpected ways how some people could use your code - are correct?

In your specific case, I most likely would consider that my current implementation of equals is correct. And all other ways were not correct. So, it was a bug and I fixed it. Then it isn't a breaking change.

@grv87 commented on GitHub (May 17, 2019): Key question: do you think unexpected ways how some people could use your code - are correct? In your specific case, I most likely would consider that my current implementation of `equals` is correct. And all other ways were not correct. So, it was a bug and I fixed it. Then it isn't a breaking change.

GiteaMirror commented

2026-06-13 12:53:51 -05:00

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

@theonlygusti Hope it's more clear for you now. Feel free to re-open this issue if there are still some questions

@ljharb and @grv87 thanks for answers

@alexandrtovmach commented on GitHub (Jun 10, 2020): @theonlygusti Hope it's more clear for you now. Feel free to re-open this issue if there are still some questions @ljharb and @grv87 thanks for answers

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4622