|Stalled||Krinkle||T267889 Update Fresh from Node.js 10 LTS to Node.js 14 LTS|
|Open||None||T267890 Upgrade all CI jobs for WMF-deployed projects from Node 10 to Node 14 LTS|
|Open||None||T267888 Create WMF CI image for Node.js 14|
|Declined||None||T267891 Create Debian packages for Node.js 14 upgrade|
Not sure what this task rationale is.
Debian buster has node10,
and will provide security updates until at least 2022.
The next version of debian, bullseye, currently has node 12
and will eventually upgrade to node 14, probably before release.
So if the only reason for building node 14 packages, I consider the request declined. I'm happy to revisit if there are other reasons for which we need a production-ready node 14 installation.
I don't think Debian provides security support for the 1,446,739 packages on npmjs.org. It won't be long before our production services or CI tooling will no longer function on a supported version of its dependencies on Node 10.
The rationale is that developers are adopting newer versions on a different timeline than the Debian releases. Either we are ahead (the case for NodeJS) and/or we stick to an older version (the case for PHP: Stretch has 7.0, Buster has 7.3, we use 7.2).
For the recent NodeJS upgrades:
- The service team had a task filed to adopt NodeJS 6 even before Debian Stretch got released with NodeJS 4.8.2 and we switched our services to NodeJS 6 in January 2017 using Jessie as a baseline (T149331).
- The upgrade to NodeJS 10 was similar, we have migrated CI and services using Debian Stretch as a baseline (T210704) by having NodeJS 10 packaged for Stretch (T203239).
This request is similar: provide a NodeJS version which is ahead of Debian schedule since developers will surely adopt NodeJS 14 before it gets included in a Debian release.
Debian testing / unstable currently has NodeJS 12, experimental has NodeJS 14. The next Debian release will be frozen two months from now (January 2021). We thus have two different timelines:
A) NodeJS 14 get promoted to testing before the freeze in January 2020 and thus will be included in Debian Bullseye which should be released in July 2021. We would thus freeze this task and hold our adoption of NodeJS 14 for ~ 8 months.
B) They stick to NodeJS 12 and we would have to manage a backport ourselves. Either on:
B.1) Buster (which gives us NodeJS 14 "immediately")
B.2) Bullseye when it is released (and wait ~ 8 months).
I have asked the package uploader (Jérémy Lal).
Reply from the package uploader:
indeed, all other things being equal, nodejs 12.x will be in debian 11.
(unless a developer starts working full time on transitioning nodejs 14 to testing, which is unlikely to happen before release freeze).
Which implies Bullseye will ship NodeJS 12 and discards timeline A from above. Thus to support Node JS 14 either we backport to Buster or wait for Bullseye to be released and backport to it.
While nothing above seems to contradict that we don't have a compelling reason to install node 14 packages for production now, I want to make a point: developers don't just decide to use a newer version of some software in production in a void.
We want to stick to versions that are supported by our distribution of choice to reduce the already overwhelming burden of keeping up with security updates for our team. Now that we work in containerized environments it's faster to switch software distribution and node version, keeping what's currently supported by our distribution, which means we won't have to maintain the package and follow closely releases from upstream.
If we need to use node14 in CI for some reason, you can download whatever version of nodejs in your container in CI as you see fit, btw.
I didn't notice the task was opened again, I will decline again as I don't see a need for a node 14 package to use in production. CI can easily use the binaries from nodejs.org, as I stated above.