I love this.<p>I think to expect perfection in timing and aligning work done by humans, even where someone could make reasonable foresight arguments, is overlooking how challenging this wide level of supporting an ecosystem is.<p>The response they made is in regards to security and making ut clear to users that they are expected to be anti-fragile to change. Even if the roadmap itself changes.<p>I've changed decisions, even flip-flopped several times due to uncertainty. When at the heart of the message they are acting with positive intent, I applaud their short, sweet, and to the point message along with their reasoning.<p>I worked with an organization that allowed TLS 1.1 for far too long because customers systems hadn't been updated. If they paid enough money, we had to allow it. Meanwhile we were getting beat up by the competition because, "Why would any good development company allow this?!?"
AWS Lambda[0] and GCP Functions[1] both say they support only up to Node 16 today. Hopefully they'll get new versions shipped with enough lead time for customers to upgrade ahead of the deprecation. (There are things like Cloud Run to bring your own container that could be used sooner)<p>[0]: <a href="https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html" rel="nofollow">https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.h...</a><p>[1]: <a href="https://cloud.google.com/functions/docs/concepts/nodejs-runtime" rel="nofollow">https://cloud.google.com/functions/docs/concepts/nodejs-runt...</a>
Great communication from the team.<p>Here’s our choices. Here’s our thinking. Here’s what we decided and why.<p>Not ideal but it’s still over a year from now which gives folks time to plan.
It seems like the most reasonable choice. Incidentally, I have an open-source tool called Node Version Audit [0] which checks a given node version against known CVEs and end-of-life dates. It looks like the official change hasn’t been made yet [1].<p>[0] <a href="https://www.github.developerdan.com/node-version-audit/" rel="nofollow">https://www.github.developerdan.com/node-version-audit/</a><p>[1] <a href="https://raw.githubusercontent.com/nodejs/Release/main/schedule.json" rel="nofollow">https://raw.githubusercontent.com/nodejs/Release/main/schedu...</a>
I don't know why people are complaining that they should have done things differently. 15 months is sufficient to migrate any application to Node 17.<p>But let's be real, everyone on Node 16 is going to forget about this and panic next August. Then it'll take a Herculean effort by a few heroes in each company to pull off the migration under a tight deadline of a few weeks.
Why didn't they foresee this before releasing Node.js 16? OpenSSL 1.1.1's lifecycle[0] was known well in advance of the Node.js 16 release. Why did they release it with an EOL date they could have known was impossible, and then <i>later</i> change the EOL date? This seems like a release engineering failure. Communication now is great but they had an opportunity to get this right from the beginning. As a result, we can all now be certain that Node.js's LTS support dates don't mean anything; they don't have the engineering discipline to make support promises they can keep. On multiple occasions now they've shortened their published LTS support periods after the fact.<p>[0] <a href="http://web.archive.org/web/20210403090336/https://www.openssl.org/policies/releasestrat.html" rel="nofollow">http://web.archive.org/web/20210403090336/https://www.openss...</a> -- this is prior to Node.js 16's release
As an aside, what is the obstacle to wider LibreSSL (<a href="https://www.libressl.org/" rel="nofollow">https://www.libressl.org/</a>) adoption, including node? Have the original SPOF and code quality issues been resolved by OpenSSL?
The biggest impact of this change is for organizations with big codebases who want to stay on LTS versions.<p>With the canonical schedule you can do an upgrade every 2 years, skipping over every other LTS. eg you could go from Node 14 to Node 18 to Node 22.<p>But with the early EOL, if you're on Node 16 you can't jump to Node 20, so you have to do an extra upgrade.<p>For companies with big production codebases it can be a lot of work to qualify new releases.<p>It would be great if the Node team pulls forward Node 20 LTS by 6 months to preserve the skip-every-other pattern.<p><a href="https://nodejs.org/en/about/releases/" rel="nofollow">https://nodejs.org/en/about/releases/</a>
According to <a href="https://nodejs.org/en/about/releases/" rel="nofollow">https://nodejs.org/en/about/releases/</a> (which has not been updated with the new schedule), nodejs 18 maintenance status will start on 2023-10-18, which means there will be a bit more than a month without a maintenance LTS version. It would be nice if they could also advance this date to match the new EoL of node 16 so people that are not interested in backported features can live their stable and regression-free life quietly :)