Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update supported platforms for Node.js 12 #26714

Closed

Conversation

@rvagg
Copy link
Member

commented Mar 17, 2019

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).

BUILDING.md Outdated
| GNU/Linux | armv6 | kernel >= 4.14, glibc >= 2.24 | Experimental | Downgraded as of Node.js 12 |
| GNU/Linux | ppc64le >=power8 | kernel >= 3.13.0, glibc >= 2.19 | Tier 2 | e.g. Ubuntu 16.04, EL 7 |
| GNU/Linux | s390x | kernel >= 3.13.0, glibc >= 2.19 | Tier 2 | e.g. EL 7 |
| Windows | x64, x86 (WoW64) | >= Windows 7/2008 R2/2012 R2 | Tier 1 | [2](#fn2),[3](#fn3) |

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 17, 2019

Author Member

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

This comment has been minimized.

Copy link
@refack

refack Mar 17, 2019

Member

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

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 18, 2019

Author Member

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.

This comment has been minimized.

Copy link
@refack

refack Mar 18, 2019

Member

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

This comment has been minimized.

Copy link
@joaocgreis

joaocgreis Mar 18, 2019

Member

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.

This comment has been minimized.

Copy link
@refack

refack Mar 18, 2019

Member

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

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 19, 2019

Author Member

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?

Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md
Show resolved Hide resolved BUILDING.md Outdated
Show resolved Hide resolved BUILDING.md Outdated
BUILDING.md Outdated
| Binary package | Platform and Toolchain |
| --------------------- | ---------------------------------------------------------------------- |
| aix-ppc64 | AIX 7.1 TL05 on PPC64BE with GCC 6 |
| darwin-x64 (and .pkg) | macOS 10.11, Xcode Command Line Tools 7 with -mmacosx-version-min=10.7 |

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 17, 2019

Author Member

TODO: pending discussion

| aix-ppc64 | AIX 7.1 TL05 on PPC64BE with GCC 6 |
| darwin-x64 (and .pkg) | macOS 10.11, Xcode Command Line Tools 7 with -mmacosx-version-min=10.7 |
| linux-arm64 | CentOS 7 with devtoolset-6 / GCC 6 |
| linux-armv7l | Cross-compiled on Ubuntu 16.04 x64 with [custom GCC toolchain](https://github.com/rvagg/rpi-newer-crosstools) |

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 17, 2019

Author Member

Untested, nodejs/build#1731

Show resolved Hide resolved BUILDING.md Outdated
* `gcc` and `g++` 4.9.4 or newer, or
* `clang` and `clang++` 3.4.2 or newer (macOS: latest Xcode Command Line Tools)
* `gcc` and `g++` >=6.3 or newer, or
* `clang` and `clang++` 3.4.2 or newer (macOS: Xcode Command Line Tools >= 7)
* Python 2.7

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 17, 2019

Author Member

@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?

This comment has been minimized.

Copy link
@thefourtheye

thefourtheye Mar 25, 2019

Contributor

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

| Windows | Visual Studio 2017 with the Windows 10 SDK on a 64-bit host |
| macOS | Xcode / Apple LLVM >= 7 |

### Official binary platforms and toolchains

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 17, 2019

Author Member

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

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Mar 17, 2019

@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

This comment has been minimized.

Copy link
Member

commented Mar 17, 2019

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)

@refack refack added this to the 12.0.0 milestone Mar 17, 2019

richardlau added a commit to richardlau/node-1 that referenced this pull request Mar 17, 2019

BUILDING.md Outdated
the broader community.
the broader community. All commits to the Node.js repository are tested on
multiple variants of these platforms. Breakages are considered critical for
the purpose of creating releases.

This comment has been minimized.

Copy link
@Trott

Trott Mar 18, 2019

Member

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?

BUILDING.md Outdated
* **Experimental**: May not compile or test suite may not pass.
These are often approaching Tier 2 support but are not quite ready.
There is at least one individual providing maintenance.
vendor of the platform. All commits to the Node.js repository are generally

This comment has been minimized.

Copy link
@Trott

Trott Mar 18, 2019

Member

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?)

This comment has been minimized.

Copy link
@rvagg

rvagg Mar 18, 2019

Author Member

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
Copy link
Member

left a comment

LGTM with one small comment.

@rvagg rvagg force-pushed the rvagg:rvagg/node_12_platforms_building.md branch from 502b8e3 to b923598 Apr 18, 2019

@rvagg

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

Discussion in nodejs/build#1773 made me realise we should capture the compatibility benefits of devtoolset-6 in this doc because of the confusing situation between minimum compile systems and minimum supported systems for our binaries. Even though we have minimum building requirements of GCC 6 which puts you on Ubuntu 18.04 (or 16.04 with the toolchain ppa) level of distributions, with devtoolset-6 on EL 7 our binaries have super powers. So in the latest commit, b923598, I've added a footnote to the binaries table:

7: The Enterprise Linux devtoolset-6 allows us to compile
binaries with GCC 6 but linked to the glibc and libstdc++ versions of the host
platforms (CentOS 7 / RHEL 7). Therefore, binaries produced on these systems
are compatible with glibc >= 2.17 and libstdc++ >= 6.0.20 (GLIBCXX_3.4.20).
These are available on distributions natively supporting GCC 4.9, such as
Ubuntu 14.04 and Debian 8.

@refack @mhdawson ^ (@Trott if you have language adjustment suggestions, go ahead and push 'em in)

@BethGriggs BethGriggs referenced this pull request Apr 18, 2019

Merged

v12.0.0 proposal #26930

@mhdawson

This comment has been minimized.

Copy link
Member

commented Apr 18, 2019

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

rvagg added a commit that referenced this pull request Apr 18, 2019

build: increase MACOS_DEPLOYMENT_TARGET to 10.10
PR-URL: #27275
Refs: #26714
Refs: nodejs/build#1768
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>

@rvagg rvagg force-pushed the rvagg:rvagg/node_12_platforms_building.md branch from b923598 to aa094e3 Apr 18, 2019

@rvagg

This comment has been minimized.

Copy link
Member Author

commented Apr 18, 2019

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 #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 nodejs/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 rvagg force-pushed the rvagg:rvagg/node_12_platforms_building.md branch from aa094e3 to 42e1887 Apr 19, 2019

@rvagg

This comment has been minimized.

Copy link
Member Author

commented Apr 19, 2019

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.

@targos

targos approved these changes Apr 19, 2019

@rvagg rvagg force-pushed the rvagg:rvagg/node_12_platforms_building.md branch from 42e1887 to 6894480 Apr 20, 2019

@rvagg

This comment has been minimized.

Copy link
Member Author

commented Apr 20, 2019

Landed in b581d59

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.