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