Browser-compat-data: Update Node.js versions

[demurgos]

Hi,
I'd like to propose the following changes to the recognized Node.js versions

• Add versions corresponding to io.js. Between Node 0.12 and Node 4, core Node.js developers were working on a fork called io.js due to governance disagreements. The changes made during this period were merged into Node. Some features were introduced during this period so the corresponding versions (from 1.0.0 to 3.3.1) are more precise when providing data. For example, most of the ES6 features were introduced during the io.js fork (the flag for function rest parameters was added in io.js 3.0.0).

• Use semver-minor precision. Node.js uses semver for its releases. Some features where introduced during semver minor updates. There are only two semver major Node releases per year so having a semver minor precision would be more exact. I don't think we need semver patch precision because I don't think they introduce any features (it may still help for eventual bugs, there are not a lot of these releases). For example, dynamic imports were added in Node 9.6.0. Node maintains several major versions in parallel: they are first "current" and then can go into "LTS" mode. I think that only "current" releases should be included because I am not sure how to represent backported changes (and don't think they affect feature changes very much).

  Edit: Both current and LTS must be listed because of the browser status (retired, current, planned)

[demurgos]

After thinking more about it, I don't think minor versions are needed if major versions represents the last release with this major version. It would match the way Node's documentation is versioned.

I still thinking that it may be good to add the three versions published during the io.js fork (1, 2 and 3)

[Elchi3]

I also think that minor versions aren't needed. I think we could decide this case by case, though. If 9.6 did introduce a feature, we might want to add that version to the allowed versions.

I don't know much about io.js. Will need to investigate more if io.js 1, 2, 3 versions are worth adding.

[demurgos]

Here are some pros/cons to have the versions 1, 2, 3:

Pros:

• Node's changelog assumes io.js as part of Node's history. There is a dedicated entry for these versions and they are just listed as "other versions".
• These versions are old and reached EOL. Despite that, they were used by companies that are now looking to update and having compat data about these versions would be valuable.

Cons:

• io.js happened a few years ago and is hardly used today.
• The API documentation for these version is not hosted on Node's website (as opposed to the pre-1.0 or 4+ versions).

Notes:

• I was unable to find usage shares comparing io.js and Node. It was a popular project with many articles written about it, but I cannot back it with numbers.

[eduardoboucas]

I don't have any statistical data to back this up, so I can only speak from my experience – please take it with a pinch of salt.

I think io.js has been irrelevant for a long time. For code running on the client, it may be reasonable to support ancient versions because developers don't have any control over the software installed on the consumer side. On the server, however, I don't see why anyone would still be running an ancient version of an environment that is relatively easy to upgrade without fundamental breaking changes. And if developers running io.js care enough about compatibility issues in their system to actively check MDN data, they will probably move away from it in the first place.

[Elchi3]

Ok, it seems like io.js versions are not worth the trouble and we will only add minor nodejs versions if we need to.

Closing.