-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Comments
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 ( |
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. |
Here are some pros/cons to have the versions 1, 2, 3: Pros:
Cons:
Notes:
|
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. |
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. |
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
andLTS
must be listed because of the browser status (retired, current, planned)The text was updated successfully, but these errors were encountered: