Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Node.js versions #1747

Closed
demurgos opened this issue Apr 6, 2018 · 5 comments
Closed

Update Node.js versions #1747

demurgos opened this issue Apr 6, 2018 · 5 comments
Labels
data:browsers Data about browsers (versions, release dates, etc). This data is used for validation. data:js Compat data for JS/ECMAScript features. https://developer.mozilla.org/docs/Web/JavaScript

Comments

@demurgos
Copy link
Contributor

demurgos commented Apr 6, 2018

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
Copy link
Contributor Author

demurgos commented Apr 9, 2018

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 Elchi3 added data:js Compat data for JS/ECMAScript features. https://developer.mozilla.org/docs/Web/JavaScript data:browsers Data about browsers (versions, release dates, etc). This data is used for validation. labels Apr 11, 2018
@Elchi3
Copy link
Member

Elchi3 commented Apr 11, 2018

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
Copy link
Contributor Author

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
Copy link

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
Copy link
Member

Elchi3 commented Apr 18, 2018

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.

@Elchi3 Elchi3 closed this as completed Apr 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
data:browsers Data about browsers (versions, release dates, etc). This data is used for validation. data:js Compat data for JS/ECMAScript features. https://developer.mozilla.org/docs/Web/JavaScript
Projects
None yet
Development

No branches or pull requests

3 participants