Node-sqlite3: builds: deprecating support for version that have reached end of life

[mourner]

Currently Travis builds for this repo take an excessively large amount of time:

Ran for 59 min 31 sec
Total time 4 hrs 38 min 17 sec

This is due to it being tested on 22 (!) Electron versions and 19 (!) Node versions. This seems quite redundant — many of these reached End of Life (e.g. Node <8), or are intermediary development versions that were succeeded by stable ones (e.g. all odd Node versions except the last one).

I think this needs a thorough cleanup so that it doesn't fill up Travis resources so much, leaving other projects hanging in the queue for a long time. Even for a project of this scale, I would expect 3-4 times less jobs.

cc @kewde @mapsam

[EmilioCristalli]

maybe, as a first step, just reduce the node versions to those listed as supported in the Readme?
(The sqlite3 module works with Node.js v4.x, v6.x, v8.x, v10.x, v11.x and v12.x.)

Will open a PR just in case you guys think it's worth it

[kewde]

The CI environment is also the main source for the prebuilt binaries of the releases.
I can not do a release for a version without having it in the CI.

So removing them, means not supporting them at all. It's hard to decide which versions to stop supporting without knowing which version isn't being used anymore.

Perhaps the mapbox team could tell us the statistics, how many downloads a particular version gets from the S3 bucket. That way we can make a more informed decision.

[EmilioCristalli]

that's a good point.

yeah, I was thinking about not supporting them at all. Looking at the Readme it seemed like they weren't supported anyway. And I think Node doesn't maintain them anymore

But, agreed, would be nice to see some stats

[mourner]

@kewde personally I think that regardless of download stats, node-sqlite3 should only support Node versions that are officially maintained, and drop pre-building binaries for unmaintained/legacy versions (shouldn't be a big deal). But it would be nice to get a second perspective — @springmeyer what do you think?

[springmeyer]

I agree @mourner - and the way to ensure that works without breaking downstream users unnecessarily (who may be using older node or electron versions) is to do a major semver bump when older versions are removed.

[sgillies]

@springmeyer @mourner if we can't reduce the size of the matrix now, what would you think about reducing the number of concurrent builds? Other projects can get backed up behind this one. Would 2-3 be an okay cap?

[kewde]

Node v10 will be the lowest version it should be able to work with as it still receives maintenance.
Electron v6 (which is basically Node v12 so don't worry), maintenance.

Including a major semver bump as suggest by @springmeyer

:+1: for agree
:-1: for disagree