A practical approach is to only support the LTS version

[ghinks]

If the aim is to make sure that the enterprise can adopt and choose to subsequently support node then the LTS path makes the most sense. Enterprise upgrade less often and stick to the LTS versions.

We have to also be practical in that the weight of maintenance would eventually not be sustainable for anything other than the current LTS.

Originally posted by @ghinks in https://github.com/_render_node/MDU6SXNzdWUzOTIyNzk4MTA=/issues/unread_timeline#issuecomment-448401317

[ghinks]

I think it is worthwhile openly addressing what the intent and goals would be of only supporting LTS. My concern is that the work of doing otherwise will eventually not be practical.

[ljharb]

I highly disagree that we should be encouraging this.

If I'm on node 4 (which is EOL), and I'm using a package that suddenly drops support for node 4, then my future node 6 upgrade is harder because i'd have to upgrade the package and the platform simultaneously. This happens all the time in practice.

The thing that ensures that people can most smoothly upgrade to the latest version of the platform is when packages support as far back as possible, to minimize variables and thus risk and complexity of the upgrade.

[wesleytodd]

As I said here, supporting the current/future versions at the time of a major release is the only way to follow semver as dropping node version support is a breaking change. That being said, I agree with @ljharb on the goal being as wide of support for modules as possible.

[ljharb]

@wesleytodd totally agree, in the sense that nothing about "only support LTS" or "support as far back as possible" either forces compliance nor violation of semver :-)

[wesleytodd]

Yeah, I think my phrasing in both of those comments was ambiguous. My intent was to say that "changing node version support without major version bumping breaks semver". And secondly, the process express uses is to support all current and future supported node versions at the time of release. In the past this has been "as far back as possible" by happenstance (4.0 being years old now). With the release of 5.0 we will officially support all current supported versions, which will be 6 or 8 I think.

[ljharb]

@wesleytodd my personal opinion is that that approach for express is fine as long as you're diligent about backporting both bugfixes and new features to v4; that way the upgrade from v4 to v5 will have minimal consequences for a user trying to upgrade to v5.

[wesleytodd]

Yep, we are very diligent :)

Sadly this diligence coupled with the number of support requests we get means the 5.0 branch has been in development since 2015.

As a reference for this diligence: expressjs/express#3714

This feature was made originally as a breaking change for 5.0, but we back ported it to 4 and it still might not land there lol.

[Eomm]

Maybe could be a good practice to tag the older versions of a module with an @node4, @node6 etc.. where the @lastest supports the current/future versions instead?
I think this could help some semver errors

Unfortunately, the engine property on package.json is not so used (and engine-strict was removed)

[ljharb]

That’s because declaring enforced explicit engine compat is harmful to the ecosystem; it’s a good thing npm no longer enforces it.

[ghinks]

So I am glad there is lots of discussion on this topic. It is important to clarify what our intent is so we can fully understand the outcome of that intent. I was allowing a good gap between my initial post and my response. So @ljharb you are correct. It is best to support all. But we have to be practical. There will be a finite amount of work possible and the majority of users will not be using the older versions. I completely agree this is a brutal dictatorial view but this is a group of volunteers, energy and time must be allocated carefully.

• Compromise will be inevitable
• Resources will be finite
• Enthusiasm may wane

My caution is based on the past eco systems that have waxed and waned. I know some of what I'm saying is a little unpalatable but I am counseling caution in our initial intent.

[ljharb]

All of that is true! I’m claiming tho that the effort is minimal what with CI and babel :-) we’ll have to look at it case by case.

[mcollina]

All of that is true! I’m claiming tho that the effort is minimal what with CI and babel :-) we’ll have to look at it case by case.

Node.js landed 280 breaking changes in Node 10.0.0. Depending on the module, maintaining support for different version of Node.js is extremely hard. Express was broken in Node.js 10 for more than 6 months without anybody noticing.

I maintained readable-stream@2 that worked from Node 0.8 to Node 8. I'm sorry, but the changes are not just on the language syntax (that you can easy polyfill), but also on changes in Node.js itself. Maintaining backward compatibility is hard work, and most maintainers prefer not to do it.

[wesleytodd]

Node.js landed 280 breaking changes in Node 10.0.0.

Express was broken in Node.js 10 for more than 6 months without anybody noticing.

This is specifically what CITGM is for. The reason it was not caught was because the module effected was not in CITGM. If we had #84 this would go a long way to making this more manageable.

most maintainers prefer not to do it.

I think the opportunity here would be to help them do it. Things like common codemods we could provide would also help.

[mcollina]

This is specifically what CITGM is for. The reason it was not caught was because the module effected was not in CITGM. If we had #84 this would go a long way to making this more manageable.

I 100% agree. I made this example to show that it is not simple to support multiple Node.js versions, and it is not only about JS syntax or transpiling. I think we could make it simpler.

[ghinks]

From some of the discussions on other issues I think that as long as we can focus on a small number of key packages to begin with we could rest this until the number of packages being addressed would require a rethink of which node versions to support. Perhaps @ljharb focus on highly used express modules will provide enough scope to limit the work.
But this question of node versions will keep running till we cannot deliver or limit it to very defined modules. Perhaps not all modules get all node versions? That would be a practicle compromise.