Clarifying supported Node.js versions #466
Conversation
I found "most recent LTS" a bit vague. With this change you can go to https://nodejs.org/en/about/releases/ and clearly see which versions are supported.
|
My feeling on this is that we should support as many node versions as is practical. To me that means all LTS versions (including node 10 at the time of writing). We are in a fortunate position in that we are pushing the boundaries of technology so don't really think twice about reaching for the latest and greatest tech but our users are not always so fortunate. If we want to see the widest possible levels of adoption we need to support as many runtimes as we can. |
I agree with that, but I also think we should be able to move forward quickly. Things like the async/await refactor shouldn't be blocked by old LTS versions. The biggest change at this point in time is probably being able to use ESM modules in Node.js. I think starting such a transition early on is (at this point) more valuable than not supporting Node.js v10. Do we know if we've many people on old Node.js versions? |
|
I do not agree we should support "Current", it's either just latest Active or latest Active and Maintenance IMO. |
|
There are some download metrics available at https://nodejs.org/metrics/ - there's some churn in the data quality over the last six months (see nodejs/nodejs.org#3244) but this chart is of of the last couple of months worth of data:
I'm not sure how reliable this data is, but it shows node 10 is still the most popular version with 12 slowly narrowing the gap. |
|
The old thread this was previously decided in is at #350, which decided on Latest Active only. This PR seems to be about adding/clarifying support to also add Current. I agree with @hugomrdias, we should not support current as it's a moving target.
I agree with this, but this is a separate conversation IMO. I believe we should support all Active versions, maintenance versions are reasonable to not support atm, but we may wish to do that in the future. |
|
Aha, I think I misread it then. This PR was opened because I changed the ipfs-http-client readme to say we support the Current and Active LTS versions, which is a mistake. - what I meant to say was Maintenance and Active LTS versions, since the stats show they are the most widely used. We should not be trying to support the Current version. |
|
There seems to be agreement on not supporting Current versions (I've updated the PR). Though I think we should enable Current on CI as in the current schedule there is no overlap "Active" overlap between v12 and v14. So the open question is whether to support Maintenance or not (or whether we drop v10 now, but support v12 even if v14 is released). |
|
Maintenance and Active LTS |
I am fine with this. From October this year to May of next year this will mean we are supporting 2 Maintenance releases. Do we want to support all Maintenance releases, or limit to 1 Maintenance release? Keep in mind 3 releases will also have significant impact on CI times. We can also punt this restriction to October and see where version usage is then. |
|
I worked on this LTS process for Node.js, and the intention was for projects like It isn’t actually good for the JS ecosystem for libraries to match the support schedule of Node.js Core. Once a release line falls out of maintenance, it’s an active security liability. In some cases this isn’t even the decision of Node.js, previous maintenance schedules have been cut short because OpenSSL ended support of the version Node.js was bound to. The ecosystem needs to lead people away from these release lines before Node.js cuts support for them. It’s easy to not recognize this, but “maintenance” really means “no longer supported.” The only thing that gets back ported to those release lines are security fixes. Said another way, these release lines will soon no longer even receive critical security fixes. “Maintenance” is the bare minimum Node.js can do in good conscience, it’s a big red blinking sign that says “you need to upgrade because pretty soon this will be insecure.” IMO, Not really considered in this equation is what range of releases you support within a particular release line. Just because something like ESM lands in 12.x you may have good reason to hold off on using that feature since prior 12.x releases will break, but you also don’t want that time window to be indefinite because there needs to be some incentive to take new Node.js minor releases since they often contain critical fixes 🤷♂️ |
This is a dangerous practice. “Supporting” CURRENT is not the same thing as “depending on” CURRENT. The CURRENT line tends to be quite stable and it’s rare that code that works in LTS would break in CURRENT. If it does break then it’s either because there is an upcoming breaking change you’re effected by, which you want to be aware of long before it becomes the LTS version of Node.js, or because there’s a bug in CURRENT that you’re finding which could very well be getting adopted and even make it into LTS if you don’t log it. Getting something changed in Node.js after it has already made its way into LTS is significantly more difficult than getting it fixed in CURRENT. If you break on CURRENT and don’t discover this until it’s in LTS that also means you’re broken on the early LTS releases which are widely adopted. |
I think this is a fair point and on balance maybe we should do Active LTS and Current after all. We could try it and set another milestone to review?
I think it's reasonable to ask users to upgrade minor/patch versions of node. Major versions less so. |
When I look at the current Node.js Release Schedule, I see that maintenance releases overlap (and it looks like it's also the case in the future. Perhaps an idea would be to support maintenance released until a new maintenance release comes out. So the supported versions would be Current, latest Active LTS (it seems that there will only be one at a time in the future anyways) and latest Maintenance. Practically this would mean that for now we do support v10 until v12 becomes maintenance (October 2020), so we would drop v10 support while still being in maintenance (as @mikeal suggested). Moving forward we would then drop v12 support in October 2021. |
|
@mikeal thank you for your explaining all this. After reading through your thoughts i can get behind supporting Current. |
I think we should just go with this, as @mikeal recommended. This would also enable us to just configure CI to test the aliases and avoid the mass CI config updates we've needed to do in the past. To be explicit, we would not support any maintenance release. This would currently mean v12 and v14 only. In October this becomes v14 and v15 only. |
This reverts commit 085af13.
|
I've reverted the last commit and came back to my original proposal, which seems to have broad agreement. Reading this issue it sounds like @achingbrain @hugomrdias @jacobheun @mikeal and I agree on the current version of this PR. |
|
Yay, we reached agreement. May someone please merge this one? |
I found "most recent LTS" a bit vague. With this change you can go to
https://nodejs.org/en/about/releases/ and clearly see which versions
are supported.
I hope that reflects what the original sentence tried to say. That would
mean that as of today, we support v12 and v14. We won't support v10.