Platform requirements for Node.js 14

Let's try to sort out the platform requirements for Node.js 14 ahead of the release in April. Node.js 14 is scheduled to be released in April 2020 and End-of-Life in April 2023.

I'll make a start by filling in what we're currently doing for master/Node.js 13. Please help to fill in the table below, discuss questions raised and raise another other questions for discussion. We primarily need to identify what needs changes to build infra (e.g. updating the macOS release machines) so we can try to avoid a last minute rush.

cc @nodejs/platform-aix @nodejs/platform-arm @nodejs/platform-macos @nodejs/platform-ppc @nodejs/platform-s390 @nodejs/platform-smartos @nodejs/platform-windows @nodejs/releasers @nodejs/v8-update

Based on https://github.com/nodejs/node/blob/master/BUILDING.md, https://github.com/nodejs/build/blob/master/jenkins/scripts/VersionSelectorScript.groovy we have:

What we build and test on

Only current Tier 1 and Tier 2 platforms shown.

os-arch	release machine	tested on	supported on
aix-ppc64	AIX 7.1 TL05 on PPC64BE with GCC 6	AIX 7.1 TL05	AIX >= 7.2 TL02
darwin-x64	~~macOS 10.11, Xcode Command Line Tools 10 with -mmacosx-version-min=10.10~~ macOS 15 ?	macOS 10.10 + 10.11	macOS >= 10.11
linux-arm64	CentOS 7 with devtoolset-6 / GCC 6		kernel >= 4.5, glibc >= 2.17
linux-armv7l	Cross-compiled on Ubuntu 16.04 x64 with custom GCC toolchain		kernel >= 4.14, glibc >= 2.24
linux-ppc64le	CentOS 7 with devtoolset-6 / GCC 6		>=Power 8, kernel >= 3.10.0, glibc >= 2.17
linux-s390x	RHEL 7 with devtoolset-6 / GCC 6	RHEL 7 with devtoolset-6 / GCC 6	kernel >= 3.10.0, glibc >= 2.17
linux-x64	CentOS 7 with devtoolset-6 / GCC 6		kernel >= 3.10, glibc >= 2.17
sunos-x64	SmartOS 18 with GCC 7		>= 18
win-x64 and win-x86	Windows 2012 R2 (x64) with Visual Studio 2017		>= ~~Windows 7/2008 R2/2012 R2~~ Windows 8/2012 R2?

Actions

Move cross compiling machine for linux-armv7l off Ubuntu 16.04: jenkins,ansible: arm cross-compilers as docker containers #2290
Update BUILDING.md in core: Platform updates for Node.js 14 node#32812
devtoolset-8 on Centos/RHEL Linux on Release machines - Use devtoolset-8 on Centos/RHEL for Node.js 14+ #2242
Drop release binaries for smartos (but keep testing in CI) Platform requirements for Node.js 14 #2168 (comment) jenkins: drop smartos builds from release for 14+ #2283
macOS release machine change for notarization (probably need to change the release machine for existing versions of Node.js too) - jenkins & docs: macOS 10.15 #2199
bump minimum deployment target for macOS to 10.13 - build: update macos deployment target to 10.13 for 14.x node#32454
Windows 7/2008 R2 are no longer supported so we should remove those from BUILDING.md - win: block running on EOL Windows versions node#31954

No changes

~~Python 3 (i.e. are we ready to drop support for the out of support Python 2?)~~ no change from current

"tested on column" needs filling in but I wanted to submit this before I leave the office today.

@richardlau

Confirmed test and release machines are same OS level for:

aix 7.1
centos7-ppc64
rhel7-s390x

@richardlau do you know why we officially support AIX7.2+, but we build on AIX7.1?

I don't think we should drop Python 2 support. python3.x executables are preferred over python2.7, over python, but I don't think actually not working with Python 2 is a good idea yet, support is not onerous, complaint from users could be intense. Maybe for 15.x or 16.x.

Replace ubuntu 16.04

We already have a full set of 18.04 OS levels in CI, do you mean remove Ubuntu 16.04?

It looks like 16.04 is LTS, supported to 2025, so no need to drop it for EOL reasons AFAICT.

On the other hand, all maintenance has a cost, I don't recall us finding issues on those machines that weren't found elsewhere. Does anyone else?

I tend towards the "we should have a compelling argument to have something in CI" not "its already there, so we need to have a compelling argument to remove it".

test-digitalocean-ubuntu1804-x64-1
test-digitalocean-ubuntu1804_docker-x64-1
test-digitalocean-ubuntu1804_docker-x64-2
test-joyent-ubuntu1804-x64-1
test-joyent-ubuntu1804_docker-x64-1
test-scaleway-ubuntu1804-armv7l-1
test-scaleway-ubuntu1804-armv7l-2
test-scaleway-ubuntu1804-armv7l-3
test-softlayer-ubuntu1804_docker-x64-1

@richardlau

@richardlau do you know why we officially support AIX7.2+, but we build on AIX7.1?

We build on AIX 7.1 because (a) we don't have many AIX release machines (is it just the one?) and (b) Node.js 10 is supported on AIX 7.1. At the time we wrote the supported AIX versions we were still releasing and testing on AIX 6.1(!) due to lack of systems.

* Replace ubuntu 16.04
We already have a full set of 18.04 OS levels in CI, do you mean remove Ubuntu 16.04?

It looks like 16.04 is LTS, supported to 2025, so no need to drop it for EOL reasons AFAICT.

Sorry, misread the support dates. I meant the release machine for linux-armv7l but if Ubuntu 16.04 is supported for the duration of Node.js 14 let's keep it as-is.

Windows 8.1 hits EOL on January 2023 https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet so it doesn't make it to the end of the LTS range. Plain Windows 8 is already EOL. Looks like 2012 is good till October 2023 https://support.microsoft.com/en-us/lifecycle/search?alpha=windows%20server%202012

Notorization requires at least xcode 10 and macOS 10.13.6

With regards to the operating system level Apple don't officaly state anywhere how long they support the os for, but I think going for latest (catalina 10.15) is the best idea to help prevent us running on old software like we do now.

We could also bump up the deployment target as is set to 10.11 (I think) atm, and using the site refack used last time the market share for 10.12 and below is fairly low -

@targos

General question: are we are of any new compiler (C++) constraints that may be heading our way via V8? Are we going to struggle at any point in 14's lifetime with GCC 6? @targos you seem to be on the ball with this kind of stuff, any ideas?

Ubuntu

Ubuntu tends to be on the easier end of the support spectrum of Linux for us, mainly because of ubuntu-toolchain-r. But, 16.04 is only publicly supported till early next year. The 2024 timeframe is for ESM, which is a paid extra. I tried once to get Canonical to sponsor the project with some free ESM licenses but that never eventuated. So we probably shouldn't lock ourselves into supporting an OS that isn't getting security updates. +1 to dropping for simplication.

Re the 18.04 machines you listed @sam-github, the ones with "docker" in their name are docker hosts and don't run tests bare. So we only have 2 x64 machines in rotation and even the armv7l ones are running Debian images! 18.04 is a good default for infra-type machines for now. That should switch to 20.04 soon.

macOS

Notarization places strict requirements on our release machines as noted
Supporting older versions ties up resources
We experience very few (I can remember one) issues where older versions have needed special treatment. Xcode seems to do a good job with compatibility.

I'd be in favour of raising our minimum tested to 10.13 (High Sierra) and attempting to get all our releases onto 10.15 (Catalina).

There's also -mmacosx-version-min we need to consider, common.gypi:

'MACOSX_DEPLOYMENT_TARGET': '10.10',      # -mmacosx-version-min=10.10

Let's bump that again. I'd be fine with doing it to 10.13 as well.

Linux (x64)

I'm in favour of bumping our release machines to devtoolset-8 for 14+. This is probably complicated for non-x64 but we're not raising compiler minimums so they should be fine on devtoolset-6 as they are now. But if we can take advantage of a newer compiler toolchain while maintaining our current libc compatibility then we should probably take it.

Please only drop a platform in a major bump, so i can cleanly update nvm to stop checking after that.

nvm has a hook built in specifically for smart os, to be able to do the patches required. I’ll have to check and see if that applies to the binaries, or only to building.

jenkins: drop smartos builds from release for 14+

jenkins: drop smartos builds from release for 14+ (#2283)

Can't (easily) get GCC 4.9 on Ubuntu 18.04, we need the multilib libraries installed to make the cross-compiler work for Node 10. So it's not going to be as simple as switching over the cross compilers to 18.04 hosts even if we could maintain compatibility. We might be forced to maintain multiple cross compilers unfortunately.

An interesting alternative might be to stick this into the docker hosts as an image. Then we could have 4 cross compilers of each type waiting to be used. They just compile, mostly from ccache, and don't run tests, so aren't a massive burden most of the time. It doesn't solve ci-release (we don't use docker hosts in the same way there), but if we switched the 2 ci cross compilers over to docker and repurpose one of them to a release cross compiler then we'd still be down one machine. I might explore that option.

doc: remove SmartOS from official binaries

doc: update Centos/RHEL releases use devtoolset-8

doc: update cross compiler machine for Linux armv7

doc: remove SmartOS from official binaries

doc: update Centos/RHEL releases use devtoolset-8

doc: update cross compiler machine for Linux armv7

#2290 has landed which was the last action item left so this can now be closed. Thanks everyone.

Navigation Menu

Repository navigation

Platform requirements for Node.js 14 #2168

What we build and test on

Actions

No changes

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Platform requirements for Node.js 14 #2168

Description

What we build and test on

Actions

No changes

Activity

richardlau commented on Feb 7, 2020

sam-github commented on Feb 7, 2020

richardlau commented on Feb 7, 2020

nschonni commented on Feb 7, 2020

AshCripps commented on Feb 10, 2020

rvagg commented on Feb 11, 2020

20 remaining items

ljharb commented on Apr 9, 2020

rvagg commented on Apr 14, 2020

richardlau commented on Apr 21, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions