mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
[GH-ISSUE #708] Removing support for post-LTS Node versions #6472
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#6472
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 @nVitius on GitHub (Jun 4, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/708
I'll preface this issue with some background:
There has been a small discussion over on webpack-dev-server about updating a dependency,
chokidar, from v2 to v3. Version 2 of Chokidar has been throwing warnings when installing with npm about its incompatibility with newer node versions (14+). Version 3 was released a few years ago and retains full backwards-compatibility with the caveat that it drops support for node versions < 8.How this issue relates to semver:
Since upgrading this dependency would remove support for previously-supported node versions, it could be considered a breaking change. The question is: if the versions no longer being supported are no longer in LTS (have been out of it for years - v6 LTS in 2018, v7 in 2017), should this still be considered a breaking change?
I looked around online but couldn't find any consensus on this. Would appreciate input from semver contributors.
For reference, the issue being discusses in the other project: https://github.com/webpack/webpack-dev-server/issues/3339
@ljharb commented on GitHub (Jun 4, 2021):
Platform support/LTS status is irrelevant; dropping support for a platform version is always a breaking change.
@mvz commented on GitHub (Jun 5, 2021):
@ljharb I think semver could do with an explicit faq entry about this. I've always seen the platform as a dependency, and therefore applied https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api (not for Node, but for Ruby); Others obviously have a different opinion, and the discussion regarding chodikar is not the first of its kind.
@mvz commented on GitHub (Jun 7, 2021):
As an example of another project that treats platform the same as other dependencies, see this changelog entry from pdf-reader:
67958f5632/CHANGELOG (L2)@ljharb commented on GitHub (Jun 7, 2021):
@mvz The ruby ecosystem has a very huge problem following semver; updating a dependency that forces users to adapt things is a breaking change whether it's the platform or not. In that example, v2.5.0 violates semver and should have been v3.0.0, objectively.
@mvz commented on GitHub (Jun 7, 2021):
@ljharb I know your position, and am arguing for an addition to the FAQ to point developers to who are struggling to know what to do due to https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api. This would be a clarification of something that is already obvious to you, but not to others. Please note that 'platform' is never mentioned in the semver text.
@mvz commented on GitHub (Jun 7, 2021):
The part "whether it's the platform or not" is actually very confusing to me in light of https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api, since it seems to contradict what it says in that FAQ entry. Can you clarify this?
@ljharb commented on GitHub (Jun 7, 2021):
"What software I need installed separately so it works" is part of the public API. iow, if I have to install ruby myself, then ruby's version is part of the API.
@mvz commented on GitHub (Jun 7, 2021):
@ljharb I'm not arguing against that, I'm asking for an entry in the FAQ.
"What software I need installed separately so it works" is not a phrase in the semver spec, so I don't see how that is relevant.
@ljharb commented on GitHub (Jun 7, 2021):
I'm all for adding an entry in the FAQ; it's not up to me.
What's relevant, though, is "when i update from version X to version Y, what additional changes will i have to make so Y works?" if the answer is "literally anything at all" then it's a semver-major update, a breaking change.
@Faceli commented on GitHub (Oct 26, 2021):
2.0.0-rc.2
@Faceli commented on GitHub (Oct 26, 2021):
HBM
@Faceli commented on GitHub (Oct 26, 2021):
HBM
@Faceli commented on GitHub (Oct 26, 2021):
HBM
@Faceli commented on GitHub (Oct 26, 2021):
HBM__
@jwdonahue commented on GitHub (Nov 29, 2021):
I don't have have the time to find the thread now, but we've had endless discussion about this topic. The existing FAQ is weak and implies the assumption that the version is being applied to the API, which is almost never the case. I have written on this extensively here and on Stack Overflow.
It is clear the FAQ has to be modified, but care should be taken, as there's no one correct way to deal with this issue. It really does depend on exactly what is it you are versioning? If it's really the API, then implementation details be damned, but that is so rarely the case, that we have to point out that in most environments, the dependency tree is part of the published API. That is driven by the fact that what we are actually versioning, is the package the contains the API.
If a publisher does not publish any dependency information, then under the SemVer spec, they have every right to ignore their dependency tree when versioning their API. Otherwise, they have a responsibility to transmit breaking change information with regard to changes in their dependency tree.
@mvz commented on GitHub (Nov 29, 2021):
@jwdonahue:
It's not an assumption but is right there in the summary:
This is repeated in the specification itself.
If that is unsatisfactory, maybe the specification itself should be changed.
@ljharb commented on GitHub (Nov 29, 2021):
The API includes all of the implicit requirements - which tools and OS must be installed on the machine, what version those have, etc. Changing any of them such that a previously valid environment becomes invalid is a breaking change to the API.
@mvz commented on GitHub (Nov 29, 2021):
No, that's not what API means.
@ljharb commented on GitHub (Nov 29, 2021):
It is indeed part of the interface of the application.
@jwdonahue commented on GitHub (Dec 5, 2021):
The traditional definition of an API is a header file full of nothing but declarations (functions signatures and global data references). But the spec clearly expanded that definition. Then the FAQ entry clearly says you don't do major version bumps solely because you took a major transitive dependency bump. Pragmatically @ljharb is correct, if you break it, you own it. But whether you'll break it, really depends on tooling support and the conventions of the language/dev environment in which you are working. In an ideal world, you would only be responsible for communicating whether you broke your interface and the dependency graph would be resolved by your packaging tools.
I tried to cover more of the nuances on this topic in #716.