Re-evaluate Node.js support policy

[mgol]

Node.js >= 4.0.0 has a different release policy than earlier versions. Each 6 months a new major gets released, every even major gets promoted to LTS once the next major is released. This means that the moment Node.js 6.0.0 gets released the only Node.js LTS actively supported will be 4; when Node 8.0.0 gets released the only actively supported LTS will be 6 (v4 will still receive critical security fixes but this will be a "maintenance phase"; apps shouldn't be developed on such Nodes but only maintained so it seems fine to drop support there). See https://github.com/nodejs/LTS for more details (the graph at the bottom is pretty descriptive). Non-LTS Nodes lose support 2 months after the next Node gets released. Node.js 4 will still be supported after Node.js 5 loses support etc.

If you just support latest two Node.js releases, for half of the time there will be no Node.js LTS release that you'll be supporting; this sounds bad.

Could the support policy be changed to supporting the latest stable release & the latest supported LTS? This will still be two versions but an LTS will be supported which seems good. This is how it'd look like:

1. current state - support for Node.js 4 & 5
2. Node.js 6 gets released - support for Node.js 4 & 6
3. Node.js 7 gets released - support for Node.js 6 & 7
4. Node.js 8 gets released - support for Node.js 6 & 8
5. Node.js 9 gets released - support for Node.js 8 & 9
6. Node.js 10 gets released - support for Node.js 8 & 10
7. Node.js 11 gets released - support for Node.js 10 & 11
8. etc.

How does that sound? Ideally you'd support all stable versions supported by upstream (there is always only 1 or 2 of them) but that would complicate things a little as sometimes you'd test on 2 versions and sometimes on 3.

[jleyba]

I'm leaning towards tying the minimum supported version of node to the active LTS. So Node 4.2.0 will be supported until April 2017, at which point minimum would be bumped to Node 6.

Still need to think on it some more.

[mgol]

@jleyba That would work for me but note that in March 2017 you'd be testing on 4 Node versions: 4, 5, 6 & 7 when Node 5 would be long dead so this will be a much bigger burden for you than just testing 2 versions.

You might want to test all Nodes in the Stable or Active LTS phase; then you'd have at most three versions to support. After Node 6 release you'd support Node 4, 5 & 6, after Node 7 release that'd change to 4, 6 & 7. This would be, basically, always 2 latest releases + the oldest LTS in the active phase; always 3 versions in total.

[jleyba]

Each version of selenium-webdriver will support the active LTS and stable releases for Node at the time of release. Node releases between the active LTS and stable releases will have "best effort" support. Releases older than the active LTS, as well as any unstable release branches (e.g. "v.Next") are considered unsupported.

Support level definitions:

• supported: A selenium-webdriver release will be API compatible with the platform API, without the use of runtime flags
• best effort: Bugs will be investigated as time permits. API compatibility is only guaranteed where required by a supported release. This effectively means adoption of new JS features, like ES2015 modules, will depend on the LTS
• unsupported: Bug submissions will be closed as will-not-fix, API compatibility is not guaranteed

If Node releases a new LTS each October and a new major version every 6 monhts, our support window would be roughly:

Date	LTS	Stable
(current)	4.2.0	5.0
2016-04	4.2.0	6.0
2016-10	6.0	7.0
2017-04	6.0	8.0
2017-10	8.0	9.0

[mgol]

Sounds good! :) I'd always say latest 4, latest 7 etc. in the table, though, since that's what upstream will support. E.g. current latest LTS is 4.2.2 and latest stable is 5.1.0.

[jleyba]

I decided to keep the table as is since it's mainly for illustrative purposes. I'm open to suggestions on the text in the README