mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #534] What if only change is requiring higher version of Java #4637
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4637
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 @JMarkMurphy on GitHub (Sep 17, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/534
If the public interface does not change, but only dropping support for older unsupported versions of Java, does that constitute a breaking change?
@wizzwizz4 commented on GitHub (Sep 17, 2019):
Does anybody still use those Java versions?
@ljharb commented on GitHub (Sep 17, 2019):
Yes, because a user on that version would be broken.
@JMarkMurphy commented on GitHub (Sep 17, 2019):
Maybe, dropping support for Java 6 and 7.
On Tue, Sep 17, 2019 at 3:12 PM Jordan Harband notifications@github.com
wrote:
@ljharb commented on GitHub (Sep 18, 2019):
semver is more about theoretical breakage than actual breakage - someone somewhere might be using those versions, thus dropping them is semver-major.
@klehelley commented on GitHub (Sep 18, 2019):
What do you mean by "dropping support"? Is it "if you find an issue with new versions of the software, and you use an old Java version, we won't help you", or "new versions are compiled with Java 7 and thus people still using Java 6 will NOT be able to use it as the JVM will complain and stop if they try to"?
In the former case this is a non-technical decision, and it is up to you if you want to increase the MAJOR version (SemVer does not forbid it and it will likely make things clearer to your users) or not. In the latter case it is definitely a breaking change.
@ljharb commented on GitHub (Sep 18, 2019):
(Personally I consider both semver-major, but I do agree that the latter case is objective and the former subjective)
@jwdonahue commented on GitHub (Sep 23, 2019):
@JMarkMurphy, was your API modified to use new language support? Or is this a binary level breaking change? What packaging tool(s) are you using?
I am not a Java coder, but I think from earlier discussions, that I gather that in the Java community, if you force your customers to upgrade their environment to run your code, they expect you to bump the major version. Unless your tool-chain supports side-by-side execution of different versions of Java, you should bump the major version or expect to face the wrath of your customers. It's a judgement call, whether that wrath is worthy of avoidance.
This a among the most common questions we get here. Try searching for "transitive", "transitivity", "dependency", "dependencies" and "environment". The root of the problem is, are you actually applying the version string to an API, implementation or package of API/implementation? The spec offers the best clarity on versioning API's, but most of us are actually adapting SemVer to collections of stuff (aka; packages).
@jwdonahue commented on GitHub (Oct 3, 2019):
@JMarkMurphy, unless you have follow-up information/questions, please close this thread at your earliest possible convenience.
@jwdonahue commented on GitHub (Jan 7, 2020):
@JMarkMurphy, unless you have further questions, this thread should be closed.
@filips123 commented on GitHub (Apr 29, 2020):
I have a similar question, except not for removing support for old Java versions, but generally removing support for old language versions.
Most package managers detect if the current language version if unsupported by library/project and prevent updating to it. Because of that, it doesn't matter which type of release are you going to make, because the package manager will prevent users from updating to it and breaking stuff.
However, how does SemVer consider this?
@ljharb commented on GitHub (Apr 29, 2020):
That the package manager can also determine that for you seems independent of the version number imo; if it's breaking if it were installed, it's breaking.