Drop support for Node v0.10 and v0.12

[bajtos]

Connect to strongloop/loopback#2807

@rmg @sam-github please review cc @strongloop/loopback-dev

[bajtos]

@rmg How can we instruct ci.strongloop.com (pr-builder) to not run tests in this branch on Node v0.10 and v0.12?

[bajtos]

How can we instruct ci.strongloop.com (pr-builder) to not run tests in this branch on Node v0.10 and v0.12?

@rmg Actually, we need to do the same for CIS jenkins too, looks like it's not honouring the engine field (yet?).

[rmg]

cis-jenkins has separate checks for this. Once the change is merged, it removes the unsupported versions from the config. Before merge it uses a dynamic check that simply marks the build as passing without actually building anything.

ci.strongloop.com, on the other hand, is completely manual. We'll have to modify the projects.yml file to make changes there.

[bajtos]

@rmg thank you. The catch is that we would like to keep running Node v0.12 on CI for 2.x branches where we still support Node v0.12 while it's in LTS mode.

cis-jenkins has separate checks for this. Once the change is merged, it removes the unsupported versions from the config. Before merge it uses a dynamic check that simply marks the build as passing without actually building anything.

Does this mean 2.x branch won't be run on Node v0.12 after we remove Node v0.12 from the engines field on master? That's not what we want :(

ci.strongloop.com, on the other hand, is completely manual. We'll have to modify the projects.yml file to make changes there.

Is it possible to choose Node versions on per-branch basis? If not, then I am proposing to use a dynamic check similar to what cis-jenkins is doing and sort-circuit the build when node -v is not compatible with package.json > engines.node field. I am happy to contribute this change if that helps.

[bajtos]

ci.strongloop.com, on the other hand, is completely manual. We'll have to modify the projects.yml file to make changes there.

Is it possible to choose Node versions on per-branch basis? If not, then I am proposing to use a dynamic check similar to what cis-jenkins is doing and short-circuit the build when node -v is not compatible with package.json > engines.node field. I am happy to contribute this change if that helps.

@rmg I went ahead and implemented short-circuiting, please review: https://github.com/strongloop-internal/build-framework/pull/11

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

@slnode test please

[bajtos]

@slnode test please