Drop support for Node v0.10 and v0.12

[bajtos]

Based on the discussion below, we are going to drop support for Node v0.10 and v0.12.

For modules in release-candidate mode, we will make the change within the current major version (see the comments below for reasoning).

For other modules, we will release a new major version.

Tasks

• Modify engine field in all loopback packages to state v4 as the lowest supported Node version
  • strong-remoting
  • loopback-datasource-juggler
  • loopback-connector-remote
  • loopback
  • loopback-boot
  • loopback-connector-oracle
• Update coding style guide, require using ES6 constructs in new code (const and let instead of var, arrow functions for callbacks, etc.) - see Update style guide for ES6 loopbackio/loopback.io#187.
• Discuss with @rmg how to setup CI to honour the engine field when deciding which platforms to build.
• Write a blog post announcing the change.
• Drop Node v0.10/v0.12 support in all other loopback projects, release the change as a major version - see https://github.com/strongloop-internal/scrum-loopback/issues/1188

[rmg]

For the newer/smarter CI running on cis-jenkins, this would prevent 0.10 from being run:

"engines": {
  "node": ">=0.12.0"
}

Or after 0.12 is dropped:

"engines": {
  "node": ">=4.0.0"
}

[bajtos]

Let me elaborate in more detail why I originally proposed to drop support for Node v0.10/0.12 in LoopBack v4.

1) semver

As most of us have already experienced, when a project drops support for a Node
version in a minor/patch version, downstream consumers are facing difficult
situation. A code depending on "loopback": "^2.30.0" used to work yesterday,
but it no longer works today (on Node v0.10). The semver contract was violated.

2) still in use

Unfortunately, the fact that Node v0.10 won't be supported anymore does not
mean people will stop using it. Anyone remembers Windows XP story?

IIRC, we (IBM/StrongLoop) do have clients that are still running Node v0.10
and using LoopBack. I don't think we can drop support for Node v0.10 until they migrate.

FWIW, a recent survey has shown that there are still about 30%
of projects running on Node v0.10 and what's even worse, also about 20% of new
projects are still choosing Node v0.10:
https://semaphoreci.com/blog/2016/10/12/nodejs-versions-used-in-commercial-projects-2016-edition.html

3) little benefits

IMO, Node v0.12 does not bring any significant new features that would offset
the cost of dropping support for Node v0.10. That's why I am preferring to
wait until Node v0.12 goes out of LTS and jump straight to Node v4+.

---

Dropping support for legacy Node versions will also speed up
CI by 50% now instead of a year later (by removing altogether
like we did for OSX).

I think the CI speedup will be negligible for the following reasons:

• All Node versions are built in parallel.
• Most of CI time is spent in building dependencies. AFAIK, CIS runs the
  build on a single platform (Node version) for downstream builds.

Also note that soon after Node v6 enters LTS, a new version range Node v7 will
be published, expanding the list of Node versions to run on our CI platform.

I feel like as our underlying libs drop support, we're gonna run into issues
like the one with http-auth dropping 0.10/0.12 support
out of the blue and forcing us to lock down deps.

Dependencies no longer supporting Node v0.10/0.12 is a real problem that I did
not consider before. If we lock down the version of our dependencies to keep supporting Node v0.10/0.12, then we won't receive any more bugfixes nor security fixes.

---

It looks to me that we have to make a hard decision here and pick one of the
following:

1. Break semver in order to keep receiving bugfixes in our dependencies.
2. Keep semver with the cost of having to backport (security) bugfixes in
   dependencies ourselves.

Frankly, I don't think we have enough capacity to keep an eye on all our
dependencies (and their dependencies) and keep maintaining a Node v0.10/v0.12
compatible fork.

In that light, while I am not happy with breaking semver, it looks like the
community is forcing us to do so :(

However, there is still the question how to handle customers that are running LoopBack 2.x applications on Node v0.10. I think we still may need a maintenance version of LoopBack 2.x that supports Node v0.10 to accommodate them.

In which case, perhaps the best solution is to drop support for Node v0.10/0.12 in LoopBack 3.0 completely and shorten the LTS period of LoopBack 2.x to move it into maintenance mode very soon after LB 3.0 is released. (In maintenance mode, we back-port only critical and security bugs, this should put less pressure on us in regards to maintaining v0.10-compatible forks of our deps.)

Thoughts?

cc @sam-github @rmg @superkhau @chandadharap

[bajtos]

One more comment. My reluctance to drop support for Node v0.10 in LoopBack 3.0 comes from the fact that we are in a release candidate mode where no more breaking changes should be made. We are already using regular release numbers when publishing to npmjs.org, i.e. 3.0.0 was already published as the first release candidate.

[qpresley]

@bajtos On this last comment, is there any reason why a move to not support LB 3.x on Node v0.10 is a breaking change? I would be much more comfortable with a concrete statement that Node v0.10 and Node v0.12 are use at own risk where as LB 2.x continue to support 0.10 and 0.12 on a best effort basis.

[bajtos]

On this last comment, is there any reason why a move to not support LB 3.x on Node v0.10 is a breaking change?

loopback@3.0.0 was already published to npmjs.org, albeit as a release candidate under the next tag, and it does include support for Node v0.10 in the sense that it was running there at the time of publish. So if we add engines: >= 0.12 let's say in 3.0.1, then there is a breaking change between 3.0.0 and 3.0.1.

OTOH, when we consider this is all pre-release stuff that nobody should be using in production (yet), then dropping Node v0.10 support is probably not that bad.

I would be much more comfortable with a concrete statement that Node v0.10 and Node v0.12 are use at own risk where as LB 2.x continue to support 0.10 and 0.12 on a best effort basis.

I like the proposal to "continue to support on a best effort basis", I think that was the third option I was missing while writing my long comment above 👍

[sam-github]

I'm on the fence... LB@3 is not officially released, so maybe dropping 0.10 support isn't so terrible. But then, it was published to npmjs.org, maybe dropping 0.10 is a breaking change. Maybe post on the google group list to get feedback? Maybe post a blog entry and tweet and point people to here to get feedback on what the community thinks? Its so hard to know how many LB3 users on 0.10 :-(

[bajtos]

Maybe post a blog entry and tweet and point people to here to get feedback on what the community thinks

Good idea 👍

https://groups.google.com/forum/#!topic/loopbackjs/b9MCPOHrUgk

[bajtos]

LB@3 is not officially released, so maybe dropping 0.10 support isn't so terrible. But then, it was published to npmjs.org, maybe dropping 0.10 is a breaking change.

On the second thought, perhaps we are too cautious? For long term, I doubt anybody would care about this short episode where LB 3.0.0 and 3.0.1 did support Node v0.10/0.12 and LB 3.0.2 or 3.1.0 dropped it. Majority of users will learn about LB 3.0 at the time when Node v0.10 was already out of LTS and the first LB version they will use will be the version which has already the right set of supported engines (Node versions).

[sam-github]

I don't know if we are too cautious :-(. I think its a good idea to drop 0.10 support. I'm not sure about 0.12. Its really a question of what people want, vs how much effort it is. Its definitely some effort. Its impact is ... unknown. Maybe we will get feedback from https://groups.google.com/forum/#!topic/loopbackjs/b9MCPOHrUgk

I don't like the idea of dropping support for 0.12 while it is still in LTS... but once its out of LTS it will get increasingly hard to support.

Maybe LB support for Node versions that are no longer themselves in support should be officially "best effort", meaning we won't deliberately break them, will lock dependencies if necessary to cope with upstream breakage, but guarantee nothing.

[bajtos]

My concern with locking dependencies is that if we lock down a dependency to support Node v0.12, we won't receive any more bug (or security!) fixes in that particular dependency. I.e. users running LoopBack on Node v4/v6 will be penalised because LB is making best effort to not break Node v0.12. When I over-exagerrate, we are making a tradeoff - do we want LB that supports Node v0.12 or LB that does not have security vulnerabilities in the dependencies?

[qpresley]

I like this idea of locking them down to stick within a major release. The catch is that it requires that bugs are opened against modules that drop 0.10 and 0.12 in minor releases. This should allow you to continue to get security fixes on minors or PR them to the offending module

[sam-github]

It allows getting security fixes on minors, true, but most upstream modules don't back-port security (or any) fixes to older minors, only the latest major.minor gets fixed. We should probably be much more proactive in observing the states of our deps and identifying security fixes that need backporting, but that is hard to do. It might require observing all PRs to all dependencies, and evaluating whether they are security, which would be like drinking from a firehose. And particularly bad when the only purpose is supporting a now obsolete platform, node 0.10.

Even if upstream modules dropped 0.10 support in a semver-major change, the right thing to do, they would probably only make security fixes on the latest major, so we still wouldn't get them.

More and more I'm starting to think we should just not support Node versions that are not supported by the node project. As has been pointed out, from Oct. 31st onwards, no OpenSSL security vulnerabilities are going to be fixed in OpenSSL/node v0.10. Which puts LB2 in an impossible position on node 0.10, the underlying platform will become more and more insecure. LB2 should keep its deps up to date, even if it means losing 0.10 support, to ensure it gets javascript security and other bug fixes from its deps.

If that means that it works less and less well, or not at all on node 0.10... perhaps that is inevitable.

LB 2.x apps that run only on node 0.10 would perhaps be advised to shrinkwrap now!

Or perhaps there should even be a specific "end-of-life" special patch release of LB 2.x, that has its deps either shrinkwrapped, or tightly specified, perhaps even down to the patch, so that anybody who uses that very specific patch release of LB 2.x will find it frozen in time, but everyone else can depend on LB ^2.x, and there will be new releases to LB 2, patch releases that don't work with 0.10.

@rmg you have any ideas here?

[superkhau]

@sam-github Has pretty much hit all the main points. I would like to emphasize:

we should just not support Node versions that are not supported by the node project

I feel community would understand if we explain we follow Node core release schedule in terms of support, and lock versions up to then and there. They will have a working version of non-updating LB2 and are free to upgrade at their discretion.

but most upstream modules don't back-port security (or any) fixes to older minors, only the latest major.minor gets fixed

This is important too, and the drinking from a firehose part. Just let LB2 freeze and update LB3 going forward (selectively backporting seems impossible as we would need to monitor every dep for security fixes -- huge burden as mentioned by @sam-github).

[bajtos]

Looks like we are not going to get any more feedback from the community here and we have to make the decision ourselves.

In the light of the discussion above, I am proposing the following plan:

1. Explicitly drop support for Node v0.10 and v0.12 from LoopBack 3.x, i.e. add { "engines" : { "node" : ">=4" } } to the following repositories:

   • strong-remoting
   • loopback-datasource-juggler
   • loopback-connector-remote
   • loopback
   • loopback-boot
   • loopback-connector-oracle

2. Keep supporting Node v0.10 and v0.12 in LoopBack 2.x as long as they are in LTS mode.

   When we run into the situation that a dependency stops supporting one of LTS versions (v0.10/v0.12), then we should temporarily lock that dependency down. When the unsupported Node version goes out of LTS, then we can unlock the dependency back to "latest".

   Let's say our dependency foobar drops support for Node v0.12 now. We will lock foobar to the latest version that still support v0.12. From January 2017, v0.12 is no longer supported, thus we will remove the lock and upgrade the dependency to the latest version.

Thoughts/objections?

cc @rmg @sam-github @ritch @raymondfeng @eddiemonge @strongloop/loopback-dev

[eddiemonge]

Sounds great for LB3.

LB2 plan sounds reasonable, although since 0.10 LTS ends in 5 days, I'd be ok dropping support for that now entirely.

[sam-github]

LGTM

[sam-github]

I strongly recommend blogging about this choice.

[superkhau]

@bajtos LGTM and yes I think @sam-github idea about sending a blog out would be good (as well as updating GG with the choice).

[bajtos]

Agreed, a blog post is needed here. We have Public Holiday tomorrow and I'll be travelling next week, so this may get delayed a bit.

[bajtos]

Done. Not all projects have released the new major version, but that can happen on a slower schedule over the next few weeks.