Node Support Policy

[nathanhammond]

Rendered

[runspired]

Is there any particular package that keeps us from jumping all the way to the 4.2.x (LTS) release? I haven't encountered anything not working in the ecosystem thus far and I tend to lock things there.

[stefanpenner]

@runspired consumers of our packages are often tied to specific installations of node. For example ghost (which supports node LTS's), slow moving shops and some mega-corps like Yahoo (although we are nearly off 0.10.x in most cases)

[rwjblue]

@erisds / @kevinansfield - I know Ghost has a specific support policy, and I'd love for y'all to review this and see where this lands RE: your own support guarantees...

[cibernox]

Maybe I'm biased, but given that ember-cli is tooling we use to build our apps, not something we need at runtime, I feel that the need of maintain support a wide range of versions is low. Even if some users needs to use node 0.10 for their backend, they can use a newer version of node with ember-cli using nvm by example.

Therefore, I think that supporting the last 2 mayor versions (now 4.X and 5.X, and in the future 5.X and 6.X) wouldn't be a harsh move.

[technomage]

I recommend the active LTS releases

[rtablada]

While I love the new and shiny 5.x I think that LTS support may be best.

Knowing what companies like Ghost are supporting will also help with that decision.

Also maybe lining up LTS support for ember-cli with the next Node LTS may be an option that makes both sides of things happy?

[grapho]

LTS Less pressure to keep up to date

[Gaurav0]

While I do support ensuring 0.12 is supported in the next LTS release, I think it is okay to drop 0.10 support sooner given that it has been deprecated for a long time, so long as we bump the major version number.

Whenever we do drop support for 0.10, we should bump the major version number to indicate a breaking change.

I think it would be premature to drop 0.12 support given that it has not even been deprecated yet. If we want to drop 0.12 support, we should deprecate it very soon, before the next LTS, and drop support in the following LTS.

[cibernox]

@grapho Pressure to the developer or pressure to the ember-cli team? Because for the ember-cli team, they are always expected to support the newest and shiniest. For the developer, probably supporting the last 2 versions of Node gives you, given the history of the project, well over 1 year to update.

@nathanhammond I wonder (I don't use node.js on a daily basis), what kind of features ember-cli wouldn't be able to leverage until April of 2018 because of supporting node 4.2 LTS until end of life (30 months)? As I stated in my previous comment, given that ember-cli falls in the tooling realm and nothing prevents users from having multiple versions of node simultaneously, if narrowing the support matrix pays tangible wins I don't think developers would be pissed by having to upgrade node.js once a year, specially how loudly we complain about non-technical not updating their browsers.

[HeroicEric]

Supporting the latest LTS sounds good to me. Another benefit of sticking with the 4.2 LTS for now is that it gives some more time for addons to update to work with npm@3.x, which is bundled with 5.x and still causes some issues.

[Gaurav0]

@cibernox For experienced developers, I agree.

But another issue we should consider is that many new developers likely have whatever version of node came with their system. For many systems, including the latest MacOSX, that is still 0.10. Are we sure we want new first time users to have to upgrade node or install nvm just to use ember-cli?

Also, is there any way to transpile on node to get new features?

[pixelhandler]

:+1: for current LTS

[stefanpenner]

It's also worth noting, the versions of node ember-cli supports, will inherently also enforce that same node version support on add-ons. e.g. If you have an add-on, and want it to be a good member of the ecosystem your add-on should work on all the ember-cli supported versions of node.

Of-course exceptions may exist, but in general ^^ likely stands true.

[ErisDS]

Our (Ghost's) version support policy is here: http://support.ghost.org/supported-node-versions/, this includes an explanation of why we support LTS.

The purpose of Node adding an LTS policy was to create a clear standard for support that the whole community can follow. It states clearly when support for certain version should be dropped and is a clear signal to every part of the community, whether you use Node directly, or Ember with Ember-cli, or you're an add-on or a project using express or Ghost or all of the above. That clarity is what builds reliability, dependability and trust for our community as a whole.

For this reason, I think Ember-cli has a responsibility to support and reinforce the Node.js LTS policy.

[stefanpenner]

@ErisDS so you are good with our above proposal ? or..

[Gaurav0]

@stefanpenner Based on my reading of the support policy, she is saying we should continue to support 0.10 until October 2016, which is consistent with @nathanhammond 's proposal but not @cibernox 's response.

[ErisDS]

Once an LTS is moved into maintenance mode we will drop support for that version.

I feel very strongly that this is a misinterpretation of the policy. Support for a node version should end when LTS ends, not when maintenance starts. I believe this needs to be clear and rigid for the benefit of the wider community.

[nathanhammond]

@ErisDS @ember-cli/core et al.:

I thought about this a great deal before making my proposal. :smile: From the Node.js Long-term Support Working Group:

1. Once a release enters LTS, no new features may be added to that release. Changes are limited to bug fixes, security updates, possible npm updates, documentation updates, and certain performance improvements that can be demonstrated to not break existing applications, etc. Semver-minor changes are only permitted if required for bug fixes. Semver-major changes are only permitted if required for critical security and bug fixes.
2. Once a release moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.

To clarify: what I'm proposing is our Node.js support for the current HEAD of the master branch. This is distinct from providing guarantees that some version of Ember CLI will run securely on each Node.js LTS release. We haven't yet proposed our plans for LTS releases of Ember CLI itself (our first LTS is probably six months away). Currently we provide no guarantees of support for any previously released version of Ember CLI–which is a gap we wish to correct and are working toward.

My primary goal with this proposal is to balance the tradeoff of stability vs. stagnation, something the Node.js community has struggled with since its inception. While an existing Node.js LTS release is actively maintained we will be able to easily and gracefully backport fixes to existing Ember CLI releases because HEAD will still be compatible with that LTS version. Dropping support when a Node.js release enters maintenance mode for HEAD can result in a higher cost for release engineering to backport critical security fixes but doesn't tie the momentum of the project to an almost three year old release of Node.js.

Not having a policy before now we believe that it's important to give people a chance to migrate off of existing versions of Node.js which we currently support (0.10, 0.12) all the way until Node.js completely drops support for them.

Given this strategy I believe that we can make this decision independent of our Ember CLI LTS release policy without worry of future conflict.

[nathanhammond]

@runspired @cibernox et al.:

Presently Ember CLI counts as tooling, but we're finding our code being used as the foundation for more and more internal and external to the Ember community. Assuming that we know how everybody wishes to extend Ember CLI would be hubristic of us. With that in mind I believe that it's important to make sure that we err on the side of caution. Yes, this could end up making us wait an additional year for async/await if it doesn't land in the next Node.js LTS, but being incompatible with the community is a far greater cost than a few language features.

[cibernox]

@nathanhammond Just one more question. Being compatible with Node 4.2 means we also need to mantain compatibility with npm 2.X with which it ships by default? Or the supported version of NPM can evolve at a different pace?

I can see the npm 2.X support being more problematic long term than supporting node itself. If being 4.2+ AND npm3+ is ok, I see less of problem in supporting the latest LTS until EOL.

[nathanhammond]

@cibernox Our npm support story is a different question entirely and outside the scope of this RFC. Ember CLI presently bundles its own version of npm and we don't see that changing. Suffice to say that we're investigating how to handle package management more gracefully.

[cibernox]

Ember CLI presently bundles its own version of npm

Those are total news to me :exclamation: Since when? Running npm install from within a ember-cli project is not using the system npm or I'm missing something?

[nathanhammond]

@cibernox

Running npm install from within a ember-cli project is not using the system npm

npm install uses the system version. ember install uses our internal version.

[stefanpenner]

@cibernox we also are planning to allow ember install to work correctly in all cases (even if the local node_modules is partial or non-existent). Before people start worrying, I plan to enumerate the idea in RFC form, so we can gain support/feedback/ideas.

The issue was, earlier we used the system npm, but navigating N different versions (with there own issues) proved quite troublesome.

---

This raises a good point, does LTS mean we are stuck with the bundled NPM for the initial ember-cli installation? Or can we assume users can upgrade npm, up to this point we have assumed users can upgrade. But maybe this needs fleshing out ..., what are your thoughts on npm version @ErisDS ?

[nathanhammond]

@stefanpenner

does LTS mean we are stuck with the bundled NPM for the initial ember-cli installation?

I believe that we need to support whatever the bundled npm version is for installation of the global ember-cli (npm install -g ember-cli). Beyond that I believe we can take control. We can support only the HEAD of each LTS branch, so whatever the most-recent bundled npm is.

[stefanpenner]

@nathanhammond so as long as ember-cli global is installable by the bundled npm, and we fix ember install, we should be in the clear.

[cibernox]

@stefanpenner @nathanhammond that sounds right. LTS sounds less of a blocker then.

[jaswilli]

I'd love to see ember-cli take a very conservative path when it comes to chasing the latest and greatest, especially if the justification is wanting to use new language features.

Not every developer or project is in complete control of what version of node they can use for all the usual reasons why legacy anything sticks around. If every project was greenfield, or small, or run by a group of likeminded people I'm sure everyone would want to be running the latest stable version of node.

Unfortunately that's not the case, and as soon as the desire to play with new language features wins over the desire to provide a stable platform for the entire community, there are going to be a lot of unhappy ember-cli users out there.

The "Alternative" proposal, in my opinion, is the prudent choice for a tooling/infrastructure project like ember-cli.

[stefanpenner]

@jaswilli it isn't just language features, although that is how the conversation started.

• old node, bundle old (questionably working) npm
• old node bundle ancient entirely unsupported versions of libuv and v8, causing real grief.
• some core API and performance are non-existent on some versions (such as execSync or vm on node 10)
• I suspect this list will grow

We will take a conservative stance (as the RFC describes), how conservative is the discussion here. So saying "you should be conservative" isn't really constructive, as that is already a fact we have decided on.

When weighing in the balance, we will aim to be as conservative as practical. I am just glad node 10 will be dropped this year :tada:

[jaswilli]

saying "you should be conservative" isn't really constructive, as that is already a fact we have decided on.

Sorry if I sounded non-constructive, or non-specific. As the last sentence of my post stated, I think doing anything other than supporting the LTS version(s) of node for their entire LTS lifespan is going to be problematic for ember-cli users.

So I'm just weighing in on "how conservative" I think ember-cli should be.

edit

When weighing in the balance, we will aim to be as conservative as practical. I am just glad node 10 will be dropped this year

😄 Yes, there will be much rejoicing.

[rtablada]

Not sure that tying to the full LTS length of Node is quite the requirement seeing how their lifecycle is meant for LTS to be built on top of.

So for instance if Node's LTS is 30 months then we shouldn't also be LTS of 30 months since 4.2 would be deprecated by the time ember-cli is EOL.

The first one might be weird since it has to sync up with both Node and Ember Core.

[ErisDS]

So for instance if Node's LTS is 30 months then we shouldn't also be LTS of 30 months since 4.2 would be deprecated by the time ember-cli is EOL.

I'd argue the very opposite. The ceasing of support for a version of Node in dependent projects should cascade FROM the end of LTS not lead up to it. Ember-cli, as a dependent, needs to follow Node's lead.. otherwise this gets super confusing.

I am just glad node 10 will be dropped this year :tada:

Me too, for sure!

To explain my perspective in more detail here, what I want is for there to be absolute clarity around what "end of LTS" means, and for the whole community to get behind it. I want to avoid the old versions hanging around indefinitely by setting expectations and creating absolute certainty about when end of life for 0.10 is.

If key dependencies all end 0.10 support at the same time, that sends a very strong and very clear message to everyone from hosts to hobbyists, and from enterprise to entrepreneurs that they must switch away from an end of life LTS by the time the LTS ends.

To clarify: what I'm proposing is our Node.js support for the current HEAD of the master branch. This is distinct from providing guarantees that some version of Ember CLI will run securely on each Node.js LTS release. We haven't yet proposed our plans for LTS releases of Ember CLI itself (our first LTS is probably six months away). Currently we provide no guarantees of support for any previously released version of Ember CLI–which is a gap we wish to correct and are working toward.

This sounds like something that can be worked with, although I'd echo @jaswilli's point that doing all this just because someone wants to use a latest & greatest version seems like a bad basis for decision making.

This raises a good point, does LTS mean we are stuck with the bundled NPM for the initial ember-cli installation? Or can we assume users can upgrade npm, up to this point we have assumed users can upgrade. But maybe this needs fleshing out ..., what are your thoughts on npm version @ErisDS ?

npm is something that definitely warrants a different discussion & some fleshing out. The unreliability of older versions is a serious issue - it reflects badly on dependent projects. There doesn't seem to be any leadership on what to do about this at the moment, and I'm keen to find some clarity as we also haven't really covered this in our LTS policy. Not sure if it's possible to find a recommended minimum version based on what's reliable?

[nathanhammond]

Regarding @ErisDS's response.

---

cascade FROM the end of LTS not lead up to it

Agreed, though we may target coincidental deprecation. /cc @rtablada

This sounds like something that can be worked with...

How should I characterize this? "Tepid assent?"

...although I'd echo @jaswilli's point that doing all this just because someone wants to use a latest & greatest version seems like a bad basis for decision making.

Agreed. @stefanpenner's response neatly addresses this.

If key dependencies all end 0.10 support at the same time, that sends a very strong and very clear message to everyone (...) that they must switch away from an (...) LTS by the time the LTS ends.

Agreed, and we can choose to match our release lifecycle and support schedule to Node.js as we become more familiar with our proposed release train model. This is still undefined for now.

npm is something that definitely warrants a different discussion & some fleshing out.

We'll post an RFC for discussion on just that topic at some point soon.

---

Another way of thinking about the last 12 months of a Node.js LTS is "life support" mode. We can deal with the cost of writing code to close critical security issues multiple times as that should be presumed infrequent (otherwise we're doing it very wrong). We're effectively saying that you won't get to use the latest and greatest features of Ember CLI on a "maintenance mode" LTS because we won't have an easy way to ship code to you. This doesn't mean that we won't be providing a stable supported already-released version of Ember CLI for that LTS (but details on that will come in a separate RFC), just that no new releases will target that platform.

@ErisDS I'm going to update the RFC to include the clarifications your questioning brought about.

[cibernox]

While I see value in supporting all alive LTS versions of node, I'd like to bring another approach that wasn't mentioned in the RFC.

Given that ember-cli gathers analytics about usage, would be reasonable to track the versions of node we use and drop support on a version once its usage falls below some threshold.

Say, once usage falls below 5% (or LTS support ends, whatever comes first) a deprecation warning is displayed asking people to upgrade, and once it falls below 1% it is removed.

That is how this kind of decisions are usually made when determining the browser matrix in the products we build, and could also be used to determine when the % of people using an ancient version is totally vestigial and it doesn't worth the effort.

[nathanhammond]

@cibernox That's a valid approach, but by not attaching a timeline to it makes it difficult for enterprises to plan for migrations. A timeline-based approach allows for planning years in advance. How do we decide when to move if a lot of people are still running an older version? It's entirely possible to get stuck in an IE6 scenario here.

[webark]

I think running slightly behind the Node LTS policy is the best bet. Currently, that would mean supporting 0.10 for ember-cli. (this kind of back support shouldn't be as large of a burden moving forward due to the recently released Node LTS policy).

However, if I was to write a new addon, would it be considered "bad form" to write it with features that where not supported prior to the current active LTS (4.x)? And then as I was working on this addon over then next year, cut a branch and a version of my addon that was pegged as a "maintenance" version only when the node v4 LTS, and subsequently ember cli LTS, gets moved into maintenance mode?

If this was considered "good form", then is there a defined method for alerting users when they do an ember install that the version of node they are using is too old, and please downgrade to X version of this addon for continued support. (might be beyond the scope of this RFC)

[rwjblue]

npm versioning aside, I think that sticking with the Node LTS policy makes this much simpler (and not directly our problem/fault). This still gets us out of supporting 0.10 in 6 months, and 0.12 in about 12 months.

---

As an aside, I think that what "support" means should likely be called out in this RFC. Does it mean that the latest stable ember-cli version supports each of the "supported" Node versions? Does it mean that we support the most recent release of each LTS or all releases? Does it mean that we will provide specific ember-cli versions for each node engine version? What does it mean for non-LTS versions of Node (i.e. 5.x)?

[nathanhammond]

@rwjblue Clarifying everything in an update. :)

[cibernox]

@nathanhammond If the TLS ends, the support should end too. That is why I added

once usage falls below 5% (or LTS support ends, whatever comes first)

I just wanted to highlight a possible scape valve in case real world analytics shows that some LTS version is negligible (0.15%) and yet the commitment initially made will holding back the other 99.85%. Decisions based on analytics seem more "fair".

Raising deprecation warnings with enough time as the usage approaches the EOL threshold point might give enough visibility for the enterprise world.

Just wanted to propose an option C

[webark]

@cibernox one issue with basing things off of usage that I've noticed in the browser world, is that you can start dividing people up into the "big dogs" and the "small fry". Meaning.. if 0.15% of your users are just random people, it's fine cutting them out, but if 0.15% is a larger corporation, then that puts them in a more "privileged" status. If you just adhere to the formal support policies, it creates more of an even playing field.

(was wanting to add a Houyhnhnm reference in there, but couldn't find a good fit ;)

[nathanhammond]

I've updated the RFC per all of y'all's feedback. Here it is rendered.

No real changes, but examples have been added, clarifications included.

[ErisDS]

This sounds like something that can be worked with...

How should I characterize this? "Tepid assent?"

My concern here is brought to light by one of @rwjblue's questions:

Does it mean that we will provide specific ember-cli versions for each node engine version?

As a build tool, ember-cli exists to be a dependency of other projects. However, if you end up not supporting ALL the LTS versions in one single version, then none of your dependents can realistically do this either. The worry is that at some point ember-cli will grandfather 0.10 support in such a way that would force Ghost to choose between 0.10 support or later LTS support meaning there'd be no technical way for us to stick to the policy that we set out ~6months ago.

If we have to hold back and stay on an older version of ember-cli that at least works for all the LTS versions we promise to support then that's at least a workable solution, but not a preferable one. We do our best to keep up with you guys and would rather not be excluded :wink:

[nathanhammond]

@ErisDS This RFC does indeed propose an approach that drops the ability to support all of the Node.js LTS versions using the master version of Ember CLI. It does not drop the ability to support all of the Node.js LTS versions using some combination of guaranteed supported (LTS) releases and our current master. Presumably as well the older releases may "just work" in more-recent Node.js releases. Any support at all for older Node.js LTS releases is already remarkably one-sided as evidenced by the reactions here.

Landing of this RFC would mean that Ghost would adopt Ember CLI's LTS releases, same as you've adopted Node.js's LTS releases. This is a tradeoff you've already elected to make and the reasons you describe apply the same here.

I'm of the opinion that maintaining full feature support for a maintenance mode Node.js LTS release is beyond even the guarantees that Node.js provides. This RFC's proposal feels in line with the spirit of the Node.js release cycle in which the oldest LTS is in maintenance mode. It's supported, but you get no new features. I also have significant concerns about the longevity of our dependencies supporting the oldest of Node.js versions and we can't afford to fork and maintain an entire ecosystem (we already own too much).

[ErisDS]

Note: I'm about to get on a plane and so this is the last reply I can write for ~12 hours.

Landing of this RFC would mean that Ghost would adopt Ember CLI's LTS releases, same as you've adopted Node.js's LTS releases. This is a tradeoff you've already elected to make and the reasons you describe apply the same here.

This might be true in theory, but in practice they are quite different.

One version of Ghost is able to support any version of Node.js. There is no configuration necessary in Ghost itself to make this possible - a user installs Node.js on their environment and Ghost master will work.

One version of Ghost is not able to support multiple versions of ember-cli. The fact that we depend on you through other mechanisms means we have to pin our support to a version, or range of versions via configuration. There is no way to switch ember-cli version based on a user having a different version of node.

What you're proposing is rendering any dependent project of ember-cli incapable of supporting Node.js's current LTS plan.

Obviously, that's not OK?

[nathanhammond]

@ErisDS Have a great flight, I'm really looking forward to continuing this conversation when you return. :smile:

[rwjblue]

@nathanhammond - The most recent round of updates definitely adds some much needed flesh to the proposal.

... will provide support for any Active (not Maintenance Mode) Node.js LTS and the current stable Node.js version(s)

I still believe (as mentioned earlier in this thread) that we should drop this caveat, and support all supported Node LTS versions.

@ErisDS - My concern here is brought to light by one of @rwjblue's questions:

Does it mean that we will provide specific ember-cli versions for each node engine version?

This is also my concern. I see very little value to drop an LTS during its maintenance mode. The point of maintenance mode is to provide overlap with new LTS as a mechanism to migrate.

[jaswilli]

This RFC's proposal feels in line with the spirit of the Node.js release cycle in which the oldest LTS is in maintenance mode. It's supported, but you get no new features.

Is it? Here's why I think not supporting the entire LTS lifetime is problematic (and please tell me if I'm misunderstanding the situation):

LTS v.something is released and people adopt it and plan on having 30 months (or whatever) with this particular LTS train. No new features is fine but bug and security fixes are still coming and (to them) that's all that matters. Now let's say that 18 months in, LTS v.somethingNew is released with a version of V8 that supports the new javascript syntax du jour. Support for v.something is dropped and [insert new language feature] makes its way into ember-cli.

Now ember-cli is broken for LTS v.something and there's no "best effort" or "should probably still work" about it. All of a sudden that "we've got LTS stability for 30 months" bill of goods I sold my team/users/whomever is no good.

[nathanhammond]

What you're proposing is rendering any dependent project of ember-cli incapable of supporting Node.js's current LTS plan. - @ErisDS

It depends on how you interpret Node.js's LTS plan (more below). I'm proposing that a user who is brand new installing Ghost would need to be aware of their Node.js version and install a packaged release of Ghost that supports that particular version as opposed to the latest tag on npm. Assuming that a user does that at the beginning of an LTS cycle their experience is unchanged and their application will run, securely, for the entire lifecycle of the LTS (36 months, including maintenance). After 24 months they'll stop receiving new features but the application will run securely and perfectly fine. At the tail end of the Maintenance period they can update their applications, achieving the no-churn thirty month promise.

I'm in effect proposing that ember-cli and Ghost adopt a support policy matching Node.js's including the lifecycle phases.

Note that Ember itself doesn't provide a guarantee of support for this long (caps at ~15 months for security releases). This is actually the primary limiting factor for Ghost upgrades right now, not Ember CLI.

---

Regarding whether or not it is in spirit with Node.js's release process, here is Node.js's description.

During Active Support:

Changes are limited to bug fixes, security updates, possible npm updates, documentation updates, and certain performance improvements that can be demonstrated to not break existing applications, etc. Semver-minor changes are only permitted if required for bug fixes. Semver-major changes are only permitted if required for critical security and bug fixes.

During Maintenance:

only _critical_ bugs, _critical_ security fixes, and documentation updates will be permitted.

In short, the Node.js team gets to effectively stop development on their LTS branch after 24 months and only backport _critical_ security fixes. During the last 18 months of that period they land only bugfixes, with very limited actual development on that branch.

This proposal provides broader support than Node.js's own proposal as it guarantees:

• Full feature support for the entire Stable => LTS lifecycle (24 months).
• (Presumably) a parallel supported LTS version supporting the oldest maintenance mode release. (The trailing 12 months.)

---

I see very little value to drop an LTS during its maintenance mode. - @rwjblue

Maintenance mode is an additional twelve months. We'll be supporting a 36 month (or older!) version of V8 at that point, or described differently, a V8 engine from 6 JavaScript library half-lives ago. This extends our support lifetime to 4x beyond what even Ember guarantees.

The point of maintenance mode is to provide overlap with new LTS as a mechanism to migrate. - @rwjblue

There is already a six month overlap period every 18 months, even excluding Maintenance mode timeframes.

I only propose dropping support for running master. I propose that it use one of our existing still-supported releases, likely an LTS release, likely one which was already intentionally adopted by our consumers. There is no reasonable use case in which a person starts a new project on an old Node.js version so the only people who find themselves in this scenario will simply have to upgrade their Ember CLI version at the same time they're updating their Node version.

I also really don't want to get into the business of dealing with the eventual ecosystem drift wherein we slowly own more and more because of people using new features in our dependencies.

[mfeckie]

I think it's pretty reasonable to only 'officially' support the LTS versions node. I've been using Ember-CLI since it started and have used it with node and iojs, old versions and the bleeding edge. Have had almost zero issues due to node/iojs version. Compared to the hell that was bower versioning this seems like less of a problem.

In an exploratory sense, are there things in Ember-CLI / on the horizon that explicitly require a specific node version??

[Gaurav0]

@nathanhammond Thanks for the update and for bringing this RFC forward! However, I looked at the recent commit and it does not address the concerns I still have regarding:

1. How soon shall we deprecate (throw a warning for users running) node 0.12?
2. Semver requires that we bump a major version number when dropping support for a node version.
3. What about node / io.js versions 1, 2, and 3? These should be explicitly mentioned.

To be clear, I am in general agreement with the timeframes and reasoning presented in the RFC.