[HN Gopher] Bringing Forward the End-of-Life Date for Node.js 16
___________________________________________________________________
Bringing Forward the End-of-Life Date for Node.js 16
Author : WalterSobchak
Score : 86 points
Date : 2022-06-11 12:06 UTC (10 hours ago)
(HTM) web link (nodejs.org)
(TXT) w3m dump (nodejs.org)
| forty wrote:
| According to https://nodejs.org/en/about/releases/ (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 :)
| lightswitch05 wrote:
| 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].
|
| [0] https://www.github.developerdan.com/node-version-audit/
|
| [1]
| https://raw.githubusercontent.com/nodejs/Release/main/schedu...
| bcjordan wrote:
| 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)
|
| [0]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-
| nodejs.h...
|
| [1]: https://cloud.google.com/functions/docs/concepts/nodejs-
| runt...
| mhoad wrote:
| I don't know the AWS ecosystem but in the meantime on GCP at
| least just use Cloud Run rather than Cloud Functions and keep
| whatever run time you want and pick up a bunch of other
| benefits in the process.
|
| Their latest version of Cloud Functions is actually using Cloud
| Run under the hood already.
| explaingarlic wrote:
| Cloud Run introduces a heap of other considerations at the
| enterprise level - container building and repository
| management which may not be managed by your team etc.
|
| Cloud Functions/Lambda are very nice in a company where you
| don't necessarily have access to making your own AMI, or
| container image etc.
|
| At least that's what we used them for at my old job. Still
| had to deal with some level of corporate tech indirection
| (E.G. We couldn't make the API gateway however we wanted, our
| account had no access to route53 etc.), but much less than
| with containers. It was just a quicker way to get code
| running.
| iends wrote:
| This is largely because Node 16 is the current LTS.
| FBISurveillance wrote:
| Node 16 graduated to LTS on 20 Apr 2021. Lambda added support
| for Node 16 just last month, basically 13 months after.
|
| I hope they add Node 18 sooner than that.
| akmittal wrote:
| Node 18 will be active LTS in October this year. So they
| will have 11 month of buffer
| rantallion wrote:
| AWS have already openly admitted that they were slow
| bringing Node 16 support and plan to be quicker next time
| round.
|
| > We recognize that customers have been waiting for some
| time for this runtime release. We hear your feedback and
| plan to release the next Node.js runtime version in a
| timelier manner.
|
| https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-
| no...
| mcnichol wrote:
| I love this.
|
| 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.
|
| 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.
|
| 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.
|
| 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?!?"
| Something1234 wrote:
| How does that work in their marketing? We are more secure cause
| we only use the latest protocol and deprecate things before our
| customers are ready?
| javajosh wrote:
| As an aside, what is the obstacle to wider LibreSSL
| (https://www.libressl.org/) adoption, including node? Have the
| original SPOF and code quality issues been resolved by OpenSSL?
| electroly wrote:
| 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 _later_ 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.
|
| [0]
| http://web.archive.org/web/20210403090336/https://www.openss...
| -- this is prior to Node.js 16's release
| charcircuit wrote:
| >known was impossible
|
| It's not impossible. They just have to support more.
| linkgoron wrote:
| I think that this is a quite harsh. The EOL for Node 16 is more
| than a year away, there's a good reason for the EOL change, and
| Node 18 will be LTS almost a year by then.
| saghul wrote:
| Chill. To err is human. They are communicating this welll in
| advance so everyone has about a full year to update to Node 18
| LTS. I'd say that is a very reasonable timeframe.
| joshmanders wrote:
| You realize they have a schedule pattern right and they
| probably didn't realize openssl EOL was in the middle of a LTS
| lifecycle.
| linkgoron wrote:
| The dates were known in advance - however, the Node.js team
| expected OpenSSL 3 to be out before the release of Node 16,
| but it didn't happen - so they had to release with OpenSSL
| 1.1.1. I think that there was some minor hope of maybe
| upgrading, but obviously it was too backwards-compatibility
| breaking to land without a new major.
|
| https://github.com/nodejs/TSC/issues/1222
| https://github.com/nodejs/TSC/pull/859
| ldoughty wrote:
| According to your linked article:
|
| > The OpenSSL 3.0 release schedule is documented on the OpenSSL
| 3.0 Release Schedule wiki page. We expect the final release to
| be in early Q4 2020.
|
| Node 16 Release date:
|
| > 2021-04-20
|
| They gave themselves 3-6 months buffer from 3.0 release to Node
| 16 release, and decided to move forward when OpenSSL was 4-6
| months behind schedule, with no idea when 3.0 would release
|
| OpenSSL was then released in SEPTEMBER of 2021, nearly a year
| late, and 4 months after Node 16's LTS start date.... As of
| April, the Node team could not know if OpenSSL was going to be
| released tomorrow, next month, or next year
|
| I think they made the right choice to keep moving forward
| instead of halting work waiting on OpenSSL to get back on
| schedule... by April 2021, when SSL 3.0 was already ~5-6 months
| behind, I would have expected them to extend support for 1.1.1
| for another few months... they didn't but that's mostly a moot
| point -- OpenSSL has committed to security fixes through the
| Node 16 end-of-life.. but the Node team isn't comfortable with
| that, so they made a change
| sanjayio wrote:
| I'd cut the Node team some slack, they've been doing
| phenomenally scheduling EOL and LTS support over the years.
| They're notifying everyone 1.5 years in advance. They have some
| of the best backwards compatibility I've witnessed in software
| which means updating will be easy.
| vbezhenar wrote:
| Why not support OpenSSL? It's unlikely that something terrible
| will happen in those 6 months and if it happens, just patch it.
| nindalf wrote:
| 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.
|
| 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.
| solardev wrote:
| > 15 months is sufficient to migrate any application to Node
| 17.
|
| If you don't work in tech, it's hard to explain to the higher-
| ups why some big software upgrade that will result in no user-
| facing improvements needs to take months off your million-
| dollar product launch.
|
| Besides, given the turnover these days in both people and
| frameworks, you're lucky if you're even still on the same stack
| 15 months later, lol
| ostenning wrote:
| > Besides, given the turnover these days in both people and
| frameworks, you're lucky if you're even still on the same
| stack 15 months later
|
| Its a sad reality of web development unfortunately
| sparrish wrote:
| A bad situation with no good solution. I guess moving the EOL was
| the least sucky thing to do.
| sanjayio wrote:
| To be fair, upgrading Node hasn't historically been tough.
| forty wrote:
| I agree for recent history at least. With that said, recent
| releases also haven't brought life changing changes either,
| so the incentive to upgrade remain low even if it's mostly
| painless.
| solardev wrote:
| M1 added a lot of headaches to that... some older libs don't
| support newer Nodes running in native Apple Silicon mode :(
|
| Upgrading from 16 to 18 on Windows or Linux took me like 2
| minutes of resolving some conflicts. That same repo took
| several days of investigation on M1, and eventually I gave
| up...
| jtwebman wrote:
| I feel they should make Node.js 18 lts sooner than when they do
| these. That way people have time to switch if they only use lts.
| leipert wrote:
| NodeJS becomes LTS in October. That leaves people 11 months to
| switch. It is out right now albeit not LTS, so you can prep the
| switch and switch as soon as it becomes LTS.
|
| If they'd move to LTS a month earlier, not a whole lot of
| people would gain something from it.
| forty wrote:
| Some people like using Maintenance LTS, which only gets
| security and bug fixes (as opposed to Active LTS which can
| also get backported features)
| nilsbunger wrote:
| The biggest impact of this change is for organizations with big
| codebases who want to stay on LTS versions.
|
| 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.
|
| 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.
|
| For companies with big production codebases it can be a lot of
| work to qualify new releases.
|
| It would be great if the Node team pulls forward Node 20 LTS by 6
| months to preserve the skip-every-other pattern.
|
| https://nodejs.org/en/about/releases/
| barelysapient wrote:
| Great communication from the team.
|
| Here's our choices. Here's our thinking. Here's what we decided
| and why.
|
| Not ideal but it's still over a year from now which gives folks
| time to plan.
| 0des wrote:
| spoils19 wrote:
| Hard agree. As a community we need to stand up for our freedoms
| and stop using Node for any kind of application, since it's
| always inappropriate. I'll take you one step further and say
| that every instance of JavaScript usage is also unnecessary,
| even for an 'interactive' frontend (spoiler: most people don't
| care about interactiveness, just look at comments on this
| site).
|
| As a fun story, I was working in Node with a senior developer
| with 4 years of experience who wanted to use a library for a
| trie, instead of simply building one. Can you believe it? I
| fully implemented one in a half day to show my colleague how
| unnecessary it was, and we actually found a few issues with the
| library that my one didn't have.
| nindalf wrote:
| > just look at comments on this site
|
| Took advantage of HN's JS based interactivity to downvote
| your comment. I might not have if the interaction had
| required a page reload.
|
| See? JS solving a real world problem.
| pessimizer wrote:
| > Can you believe it?
|
| That's nothing. Somebody tried to get me to use git for
| source control, but I showed him by taking six months off to
| write my own source control system.
| [deleted]
___________________________________________________________________
(page generated 2022-06-11 23:01 UTC)