doc: update supported platforms for Node.js 12

[rvagg]

As promised in the last @nodejs/tsc meeting, a proposal from @nodejs/build on supported platforms for Node.js 12.

Notable changes:

• Lifting compiler minimum up to GCC 6 for all Linux variants (needs some work on IBM platforms and ARMv7)
• Moving ARMv6 to "experimental", assuming a successful launch of an "unofficial builds" project to continue to provide that community with binaries, some work to be done here (armv6/pi1 will be pulled from Node 12+ CI for now)
• Moving FreeBSD to "experimental" as we have no champion remaining (freebsd will be pulled from Node 12+ CI for now)
• Moving Linux + musl to Tier 2 (I didn't check with @nodejs/build on this) because it reflects current reality in our CI—we test the latest 2 versions of Alpine and it uses musl. We don't do binaries but may do under an "unofficial builds" project.

There are some items that need clarification, I'll call them out to specific individuals inline.

macOS was one area where we didn't feel confident making a clear call and would like input from people who probably have greater expertise in the toolchains and compatibility. I'm thinking specifically of @bnoordhuis and @ofrobots (or someone on the V8 team perhaps?).

For macOS, we need to answer the following:

1. What minimum version of macOS should we support building on (we say 10.11)
2. What minimum version of Xcode and therefore Apple LLVM should we support building on
3. What version of macOS and Xcode should we compile our binaries on (currently doing it on 10.11 with Xcode Command Line Tools 7)
4. What MACOSX_DEPLOYMENT_TARGET / -mmacosx-version-min do we set for compiling our binaries (has been 10.7 for a long time, but maybe we should bring that right up to whatever the answer to question 1 is?)

Discussion in @nodejs/build suggested moving to 10.13 for compiling binaries but we didn't land on an Xcode (maybe 10) or a minimum supported version (maybe 10.11 still but with MACOSX_DEPLOYMENT_TARGET lifted to 10.11).

[nodejs-github-bot]

@rvagg build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2942/pipeline

[rvagg]

@joaocgreis @refack please confirm this reflects our discussion, it's essentially unchanged

[refack]

Maybe add another footnote that Windows 7 is expected to go EOL in 2020, and will be dropped.

[rvagg]

yeah, but Ubuntu 16.04 goes early too, there's this directly above the table to cover these cases:

Node.js does not support a platform version if a vendor has expired support
for it. In other words, Node.js does not support running on End-of-Life (EoL)
platforms. This is true regardless of entries in the table below.

[refack]

As I see it the difference is Windows7 and 2008R2 are mentioned by name...

Maybe the correct terminology is WINNT >= 6.1 as in kernel version, similar to Linux, making it independent of the "name" of the OS.

Refs: https://en.wikipedia.org/wiki/Windows_NT#cite_ref-msdn-win7-ver_27-0

[joaocgreis]

I think this is clear as it is, but to make it clearer perhaps just adding Until EOL in the Notes column would suffice?

Mentioning the full OS name looks looks much clearer to me than using WINNT version. Also note that we don't test on Windows 2012 (we only test on 2012R2). To be thorough, that would have to be added as experimental, but given the usage for that OS, I don't think this is needed.

[refack]

Yeah this list become too nuanced... I Yield to @rvagg's decision.

[rvagg]

too hard, too cluttered (my brain and this table). How about we revisit if someone raises it as an issue, maybe we're overthinking it?

[rvagg]

TODO: pending discussion

[rvagg]

Untested, nodejs/build#1731

[rvagg]

@nodejs/python is it time to bump this to Python 3 since Python 2 EOL will hit us pretty quickly in Node 12's lifetime?

[thefourtheye]

We are nearly there. But we cannot drop Python 2.7 dependency in this release.

[rvagg]

this isn't strictly related to users "BUILDING" Node but we've been needing to list this somewhere for a long time and this seems like a good place to record everything related to our versions.

[mscdex]

I'm a bit confused by these changes. For example, Ubuntu 16.04 only has gcc 5.4.0 in its official repositories, but this document now both says that we need gcc 6.3+ and that we support Ubuntu 16.04 (called out specifically as an example of tier 1 x64 support).

What is it about gcc 6.3+ that is needed to support node on those platforms anyway? Why can we not support gcc 5.x?

[rvagg]

@mscdex Newer GCC is easy on Ubuntu 16.04+ with the toolchain ppa—official and commonly used, similar to the EL devtoolsets (although they maintain libc compat which is nice for our releases). (NOTE that is much more difficult on Debian which is why we're listing Debian 9).

There's three primary pressures pushing us toward more recent GCCs:

• V8 keeps on marching toward C++17 and beyond (perhaps @ofrobots could give us some insight for the compat story beyond V8 7.4?). A lot of newer C++ features are creeping into our codebase as a result.
• As with many of these changes, we're managing our limited people-resources on @nodejs/build. If we opted for GCC 5 then we'd have to actually test it and be locked in to doing so for the next 3.5 years. We're actively trying to pare back our responsibilities because we've not been able to do a good enough job with what we have to do now. The minimum infrastructure needed to test the compat laid out here is a lot smaller than for Node 10 and prior.
• Optimisations available in GCC 6 that aren't in 5 .. or something like that .. I don't actually care about this but @refack seems passionate about it so he might chime in.

My ideal would be to still support 4.8, but that ship has sailed. I'm not totally opposed to pulling it down to 5 for Linux x64 since it just means for now that we have to keep Ubuntu 16.04 without the PPA in our mix. But, if it's at all likely that Node 13 or 14 is going to force us into GCC 6 anyway (V8?) then the overlap of GCC 4.9, 5, and 6 is going to increase our complexity because we'll need to maintain even more toolchains on test machines (or multiple test machines to cover it all) and have more switching logic for the Node version and toolchain differences (it's already quite complex, see here and here as well as additional logic embedded in some Jenkins jobs). i.e. I'd rather have few big jumps than many small jumps and I think the others on @nodejs/build share this view.

[mscdex]

I think if we're going to be supporting specific distro versions that require additional repositories to be added in order to be supported, it might be worth indicating that in the document somewhere. For Ubuntu you could link to the PPA, for CentOS/RHEL you could link to the devtoolset page.

[rvagg]

@mscdex I'll add those as footnotes to the table, perhaps the "e.g." is locking us in to more than we want though? It was only meant to be informational (and because nobody keeps kernel and libc versions in their head).

[refack]

RE compiler levels. I'd like to bring forward three points:

1. The current table states out support level for running the binaries, not for building. For example, building on Windows/ia32 is not supported (and AFAICT actually broken). Running node on Windows/ia32 is Still Tier 1.
2. We need to consider building the binaries with static libstd++ and libgcc, to eliminated any backwards incompatibilities.
3. Pending (2), I'd move to change the minimal compiler level to GCC-8. That will give us:
   • Full C++17 (and partial C++20). IIUC V8 is move to C++17 very soon.
   • The most modern optimizer. That free's performance.
   • Less toolchain bugs and security issues (e.g. spectre mitigation)

Moving to the newest stable compiler level will also alleviate BuildWG burden, in that skipping over support for GCC-6 saves us complexity, now and in the future. (For reference currently we do already support GCC-4.8 & GCC-4.9 (& GCC-6 at tier 2), and will need to for at until node8 and node10 go EoL)

[Trott]

This sentence seems to boil down to "Breakages are critical to creating releases." That can't be right, but I'm not sure what it's supposed to mean. Is it supposed to indicate that failing tests on Tier 1 platforms will block a release? Or something else?

[Trott]

Remove generally? If the statement is true without "generally", cool. If not...I'm not sure what "generally" means here. If it just means that the statement isn't strictly true, then write the statement so that it's strictly true. (Maybe "usually" instead of "generally" and drop "All" at the start of the sentence?)

[rvagg]

explained later in the sentence:

is not considered essential if there are temporary problems with the test infrastructure.

I'll try and be more clear but tbh getting rid of ambiguity with these is tricky because I'm inventing policy on the fly, they're pretty vague now and are more emergent ideas than anything concrete.

[mhdawson]

@rvagg your language in last comment sounds good to me.

[rvagg]

With Node 12 a few days away, this has to move from aspirational to reality. I've rolled back two critical changes that are unfortunate but I can't control them for the purpose of this document and what we're locking in for Node 12. Future changes in these areas will have to be dealt with as isolated cases:

• Python 3 - as far as I can tell from build: ongoing list of actions for Python 3 compatibility #25789 we're not close to being Python 3 ready, certainly not with only a few days to go. So I've rolled back to the original language and we're locking in Python 2.7. The introduction of Python 3 support will either have to be a force breaking change during the lifetime of Node 12 (that'll be an interesting discussion) or a non-breaking change that retains proper Python 2.7 support. @nodejs/python that's over to you.
• macOS - I've reverted most changes as the only thing we've been able to achieve is the increase of -mmacosx-version-min to 10.10. We're going to be building with macOS 10.11 with Xcode 8 and our docs reflect that as the lowest supported version. Was being tracked in modern macOS X (10.13, 14, 15) on MacStadium build#1732 and the aspiration was to move to 10.13 for building but there's no evidence of movement on this.

PTAL, this needs to get merged so it can get into 12 ASAP.

[rvagg]

I had some conflicts between my computers that stopped my latest from getting to this branch but it's fixed now and what's here should be good to go. A review or two would be appreciated before I merge this and I'd like to try and do it tomorrow.

[rvagg]

Landed in b581d59

thanks all for help on this and thanks @nodejs/build for all the hard work on Node 12 prep