Platform requirements for Node.js 18

[richardlau]

Node.js 18 is due out in April 2022 and is planned to last until April 2025 (https://github.com/nodejs/Release/blob/main/schedule.json). We need to plan out any required toolchain/hardware changes we want/need to make.

cc @nodejs/build

What we build and test on

From https://github.com/nodejs/node/blob/master/BUILDING.md#official-binary-platforms-and-toolchains

Binary package	Platform and Toolchain	Decision	done
aix-ppc64	AIX 7.2 TL04 on PPC64BE with GCC 8	move minimum hardware to Power 8
darwin-x64	macOS 10.15, Xcode Command Line Tools 11 with -mmacosx-version-min=10.13
darwin-arm64 (and .pkg)	macOS 11 (arm64), Xcode Command Line Tools 12 with -mmacosx-version-min=10.13
linux-arm64	CentOS 7 with devtoolset-8 / GCC 8	Need to migrate (#2741)
linux-armv7l	Cross-compiled on Ubuntu 18.04 x64 with custom GCC toolchain
linux-ppc64le	CentOS 7 with devtoolset-8 / GCC 8	Need to migrate (#2741)	✔️
linux-s390x	RHEL 7 with devtoolset-8 / GCC 8	Need to migrate (#2741)	✔️
linux-x64	CentOS 7 with devtoolset-8 / GCC 8	Need to migrate (#2741)	✔️
win-x64 and win-x86	Windows 2012 R2 (x64) with Visual Studio 2019

Compiler levels

Operating System	Compiler Versions
Linux	GCC >= 8.3
Windows	Visual Studio >= 2019 with the Windows 10 SDK on a 64-bit host
macOS	Xcode >= 11 (Apple LLVM >= 11)

Actions

• Check with IBM if remaining on Power 8 until 2025 is viable (we'll need additional machines if not).
• Any reason to move the minimum deployment targets for macOS on from macOS 10.13?
• CentOS 7 gets updates until 30 June 2024 which is within the expected lifetime of Node.js 18, so we'll need to move (probably to RHEL 8, Consider moving from Centos7 to RHEL8 for 18.x #2741).
  Refs: https://wiki.centos.org/FAQ/General#What_is_the_support_.27.27end_of_life.27.27_for_each_CentOS_release.3F
• Do we need to add Windows 11 somewhere to the CI? @joaocgreis

[rvagg]

Any reason to move the minimum deployment targets for macOS on from macOS 10.13?

No really good reason, but I'm wondering if we should just adopt a practice of incrementing this by 1 at this time every year. Then we don't have to do big jumps like we've done a couple of times. Being a few major versions behind seems reasonable enough I think and I don't recall any complaints (ever) from users about macOS compatibility—in fact the only complaint I recall was a Node core dev who insisted on running a couple of versions behind the latest macOS, but that was within the value we set for this.

RHEL 8

What are our IaaS options for this? Do our providers have RHEL options, or can we switch a CentOS machine into RHEL mode somehow? Or should we be considering containierising this build?

[targos]

It might be good to use a higher Windows server version even if it's not based on Windows 11. 2012 R2 is quite old.

[richardlau]

RHEL 8

What are our IaaS options for this? Do our providers have RHEL options, or can we switch a CentOS machine into RHEL mode somehow? Or should we be considering containierising this build?

Not ideal. Unsurprisingly IBM Cloud offer RHEL options but neither Digital Ocean nor Rackspace currently do (#2741 (comment)) although they do provide Alma/Rocky. Red Hat do provide a tool for switching (https://www.redhat.com/en/blog/introduction-convert2rhel-now-officially-supported-convert-rhel-systems-rhel) which I've not tested yet. Containerization or custom VM images are other things on my list of things to investigate.

I have an action to obtain a RHEL subscription for the Node.js project (possibly via https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-open-source-organizations) and see if we can make it work for us (i.e. the build wg). Having a subscription would immediately simplify set up for the existing RHEL7 LinuxOne machines (at the moment we have to manually copy rpms over to set up the compiler toolchain).

[AshCripps]

No really good reason, but I'm wondering if we should just adopt a practice of incrementing this by 1 at this time every year.

+1 on this as apple can be quite aggressive on dropping support for its OSes.

[sxa]

Particularly with the new Ampere Altra systems being available, we should also consider whether we need to continue to cross-compile for arm32 or whether to use an arm32 docker container on one of the Altrea aarch64 hosts for building to reduce the complexity and increase commonality with how other platforms are built.

[mhdawson]

To add to @richardlau's comment above our providers that don't have RHEL8 images built in do allow you to bring your own image(I think that is what @richardlau meant by customer VM images). I think that should be relatively easy to do and we should be able to get the images under the program to let Open Source projects use RHEL.

[mhdawson]

@joaocgreis thoughts on the Windows levels?

[rvagg]

From the trusty https://en.wikipedia.org/wiki/Glibc#Version_history table, switching to RHEL8 would give us a minimum glibc of 2.28 which ships with Ubuntu 18.10, Debian 10 (Buster), and Fedora 29. The only concern there is that it's later than 18.04, so we're ruling out those systems. But I think that's reasonable for a new release of Node.js - 18.04 users will either need to stick to older Node.js or compile themselves using a newer toolchain from ppa.

[rvagg]

Re ARMv7, our cross-compiler-ubuntu1804-armv7-gcc-8 label currently uses an 8.3.0 compiler (see), and it's on an 18.04 base so pretty compatible. As long as the 8.3.0 minimum is solid then that should be good to go I think.