Removing support for post-LTS Node versions

[nVitius]

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: webpack/webpack-dev-server#3339

[ljharb]

Platform support/LTS status is irrelevant; dropping support for a platform version is always a breaking change.

[mvz]

@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]

As an example of another project that treats platform the same as other dependencies, see this changelog entry from pdf-reader: https://github.com/yob/pdf-reader/blob/67958f5632d2c9ad1bb761b2e020a54f6c47648b/CHANGELOG#L2

[ljharb]

@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]

@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]

updating a dependency that forces users to adapt things is a breaking change whether it's the platform or not

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]

"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]

@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]

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]

2.0.0-rc.2

[Faceli]

HBM

[Faceli]

HBM

[Faceli]

HBM