doc: note that EoL platforms are not supported

[gibfahn]

Add a note to clarify that any platform that is EoL will not be
supported by Node.js.

Fixes: nodejs/build#688

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc, build

[cjihrig]

LGTM, and it sounds like a good idea to me, but we might need larger buy in from the CTC.

[gibfahn]

@ljharb FYI, the reason I suggested this is that (IMHO) the alternative is worse. Taking Node 8 as an example, if we don't do this then we need to work out which platforms will go out of support over the life of Node 8 and drop support for them now, which doesn't really seem feasible. The alternative is supporting Node on platforms where gcc and the OS itself are no longer supported.

For me this is similar to our OpenSSL policy, if the version of OpenSSL in Node goes out of support, then we stop supporting that version of Node.

I'd be interested to hear any alternatives though.

[ljharb]

I'm not close enough to the process to have a credible alternative suggestion, and I do understand the difficulty. However, what I don't understand is why the sudden EOL status of a platform inherently makes it harder to continue supporting it in an LTS line that it already works on.

[gibfahn]

For example, Ubuntu 14.04 goes out of support in April 2019, and Node 8 goes out of support in December 2019. So do we:

• Drop support for it in v8.0.0?
• Say we'll support it even though if issues come up after it goes EoL we have no real way of fixing them (so we don't really support it).
• Use this PR?

I would add that Node 8 is the first time we've actually stated which platforms we support, so it's definitely worth trying to get this right off the bat.

[gibfahn]

what I don't understand is why the sudden EOL status of a platform inherently makes it harder to continue supporting it in an LTS line that it already works on.

Others may disagree, but for me saying we support a platform means that if you have issues with that platform, we will fix them. That's not really possible if platform bugs aren't fixed.

I think the key is that it already works on., I'd say that it currently works on. We wouldn't actively want to break platforms that previously worked, and we might well continue to build and test after they went EoL, but this gives us the option to stop maintaining a platform once it is EoL.

[ljharb]

@gibfahn to me it means "if you have issues with that platform that are possible for us to fix, we will fix them". Obviously if it can't be fixed (windows filesystem issues, for example), then it simply can't be - whether it's EOL status or simple platform refusal.

[mhdawson]

I think this does need broader buy in. It would be good to get more people from @nodejs/build and @nodejs/lts to comment.

We don't actually call out specific linux distros, all we say is:

  kernel >= 2.6.18, glibc >= 2.5

It's obviously harder to catch/investigate/resolve issues if we don't have the OS version running in our builds but I think we'd still take a fix that resolved an issue for an OS even if we can't test it.

Personally I'm still undecided as I think it comes down to what we mean by "supported' and how we translate that to the distros.

[bnoordhuis]

Speaking for libuv, its baseline is (or rather: was) linux >= 2.6.18 and glibc >= 2.5 because of RHEL/CentOS 5, which is EOL now.

We are no longer going to fix bugs (barring perhaps the odd one-liner) that only affect that platform. Anything that takes more than a few minutes to triage or review, or complicates the code base in any way, has no chance.¹

More importantly, if maintaining the support code for linux < 2.6.32 (of which there is quite a bit) becomes a hassle we may decide to remove it. At that point libuv simply stops working with old kernels.

I do suspect it's going to be an academic issue, by and large. If you are still using a 2.6.18 kernel in 2017, you probably aren't habitually upgrading node.js and you won't be too surprised the latest and greatest doesn't run on the platform of your choice.

¹ That's also an answer to @mhdawson's question of what "supported" means.

[gibfahn]

@ljharb re: nodejs/build#688 (comment)

to be more precise; it's the act of shipping a change in a non-major that doesn't work, on a platform where the code previously worked, that's semver-major - simply declaring that you drop support for a platform isn't the important part, but effectively it ends up being the same thing over time.

Semver fails to precisely specify a number of things; one of these is "backwards compatible" - i believe the common definition is "did i upgrade from a version that works to this one, and something broke? it's semver-major" - which doesn't special-case "and something broke on a supported platform?".

By that logic shouldn't that apply to platforms that we've never claimed to support at all? If Node 6.0.0 happened to run on Ubuntu 6 or OS/360, and 6.10.0 doesn't, that means we should treat that as a semver-major?

---

As @mhdawson said:

I think we'd still take a fix that resolved an issue for an OS even if we can't test it.

We're happy to support people's use cases as long as it doesn't cause problems with our main platforms.

"if you have issues with that platform that are possible for us to fix, we will fix them". Obviously if it can't be fixed (windows filesystem issues, for example), then it simply can't be - whether it's EOL status or simple platform refusal.

But that's true of any platform, if someone submits a patch to get Node to work on (for example Ubuntu 8) then unless it causes issues for other platforms then we'll take it. As it's an open-source project, everything is supported on a best-effort basis.

Defining a set of supported platforms should mean that these are the platforms that we recommend, that you can be confident about using in production. There are plenty of collaborators who are familiar with those systems, we test on them in CI, and (usually) people who work on the platforms are involved in Node. A platform can not be supported but still work, and still be tested in CI. I don't think that we should be recommending that people run on platforms that are EoL. Put it another way, if your OS doesn't get updates, why would you expect Node to?

Semver doesn't seem to mention platform support at all, so I think we need to decide this one ourselves.

[mhdawson]

Thinking about it more. If it helps to encourage people to move of EOL versions, then starting that we drop support for them might be helpful, even if it does not affect what support we might give. In addition we could clarify that it also means that Node binaries may no longer run on at all on those versions.

[gibfahn]

Adding the ctc-review label, as I think this is a pretty important change.

@nodejs/ctc please review. This is approved by @jasnell and @cjihrig , and I think @bnoordhuis and @mhdawson are +1, but it'd be good to get everyone's thoughts on this.

ping @ljharb , thoughts on #12672 (comment)?

[Trott]

@nodejs/ctc please review. This is approved by @jasnell and @cjihrig , and I think @bnoordhuis and @mhdawson are +1, but it'd be good to get everyone's thoughts on this.

I defer to people on the LTS, Build, and Release teams/working groups for this.

From an end-user perspective, I agree with @ljharb. But that is superseded by the above-mentioned deference to LTS et al.

I also agree with Ben's comment:

I do suspect it's going to be an academic issue, by and large. If you are still using a 2.6.18 kernel in 2017, you probably aren't habitually upgrading node.js and you won't be too surprised the latest and greatest doesn't run on the platform of your choice.

[refack]

Personally I'm still undecided as I think it comes down to what we mean by "supported' and how we translate that to the distros.

Reading this thread again I agree with @mhdawson IMHO we need to define what "supported" means in practical terms. I think there are two main implications:

1. Will a specific version work on a specific platform?
   This entails running CI for a version line on the specific platform, asserting that new minors don't stop working (I believe this is the crux of this discussion)
2. Will we fix new issues that arise with a specific version on a specific platform (i.e. semver-patch)?
   IMHO this is something we do on a best-effort basis anyway, and will be possible if we "support" in the (1) sense or not.

As I see it if we decide not to support in the (1) sense, we could still support in the (2) sense (8.0.0 works on platform X but 8.1 doesn't, and if there are new bugs, and we have enough incentive, we cut 8.0.1 even after 8.1 is out). But this is something the Release and LTS groups need to approve.

[mcollina]

LGTM

[rvagg]

I think I agree with the essence what's being proposed here but the wording in the change really has me scratching my head. I'm having difficulty parsing precisely what it's trying to say. The wording discussed in nodejs/build#688 seems pretty clear but this seems to be saying something else.

The way it reads to me: we support node under these combinations, someone else supports the operating systems and libraries we mention here. Why does this latter part need to be said? Like someone will assume we support libc or Ubuntu? The wording in nodejs/build#688 talks about "upstream" maintainers, which I read as people outside of the core project that maintain Node for distros, like the Ubuntu or Debian people that package. Also, when we say "Node.js" are we talking about the code we ship or the project (i.e. us, in which case it should probably be saying that the Node.js project supports ...).

Sorry if this seems picky, perhaps I'm not in my right mind!

[mhdawson]

I wonder if the language in the PR changed over the span of the discussion. What I see now is:

+The below combinations are only supported for Node.js while the platforms, OS
+levels, and toolchains are themselves supported by their maintainers.

which does not mention Eol. I wonder if something like:

The community builds and tests on a number of different distributions. 
As distributions reach end of life (EoL) and we can no longer get the the
support and updates required to manage them effectively, they are dropped
from the test matrix.  As such there is a higher risk of uncaught problems
on EoL versions and the community will not be actively fixing issues on
these platforms. Therefore, we recommend that for production you move
off of versions before they become EoL.

would be better.

[gibfahn]

we support node under these combinations, someone else supports the operating systems and libraries we mention here.

@rvagg The intent was to say "if your OS or toolchain is out of support, Node.js doesn't guarantee that node itself will run on your machine", not that we'd be supporting the OS/toolchain. More than happy to change the wording.

---

The community builds and tests on a number of different distributions.
As distributions reach end of life (EoL) and we can no longer get the the
support and updates required to manage them effectively, they are dropped
from the test matrix. As such there is a higher risk of uncaught problems
on EoL versions and the community will not be actively fixing issues on
these platforms. Therefore, we recommend that for production you move
off of versions before they become EoL.

@mhdawson I like the idea of focusing on the fact that we don't run build/test on them in CI. I guess when I say "supported" I mean

if you have an issue with Node on that platform and you raise it, we will fix it

which suggests something more dependable than just the best-effort "maybe someone will do it" that is otherwise true. The other key thing we might mention is "there is no guarantee that future semver-minor or semver-patch updates won't break node on your platform".

However I don't think that much background is necessary, I think we want to be focused on the point for the user (don't expect node to just work on EoL platforms). How about:

The community does not build or test against end of life distributions (EoL).
Thus we do not recommend that you use Node on end of life or unsupported platforms
in production.

[mcollina]

The community does not build or test against end of life distributions (EoL).
Thus we do not recommend that you use Node on end of life or unsupported platforms
in production.

Does this statement mean that in LTS we support a distribution until is EoL and we can maintain the relative CI system going?
Can we note which distribution are planning to go EoL in the Node.js LTS announcement? That should answer the questio am I good to use this in production on that OS question. More importantly, when do I need to schedule an upgrade?

[Trott]

It would be great if the final tweaks on this could be worked out and if it could be landed. I'm being a bit selfish here, but as of now, this is the only item on the CTC agenda this week and the meeting is at 4am in my time zone. So if the meeting is canceled, I get to sleep. :-D

[gibfahn]

I think using an EoL platform means there's a very strong incentive to freeze the state of the system, hopefully taking all the cons into account. So for those situations IMHO there is no "easy answer" 🤷‍♂️ .

Well, the easy answer is to upgrade to a system that will receive security patches. I don't think it's unreasonable to say that you shouldn't ever be running an EoL distribution in production.

[gibfahn]

Does this statement mean that in LTS we support a distribution until is EoL and we can maintain the relative CI system going?

Yes, if it's covered in the table below as a 1st or 2nd tier platform, then we should have CI cover for it.

Can we note which distribution are planning to go EoL in the Node.js LTS announcement? That should answer the question am I good to use this in production on that OS question. More importantly, when do I need to schedule an upgrade?

I think it would be a great idea to do a blog post when a new version of Node goes LTS, to cover these "what should you use" questions. That wouldn't go into this PR though.

[bnoordhuis]

This PR has plenty of LGTMs. How about we land it?

[gibfahn]

@rvagg could you take a look at the revised wording, and let me know if you'd like it changed (and if so could you suggest some wording)?

This PR has plenty of LGTMs. How about we land it?

I'd like to make sure @rvagg is okay with it, given that he found the previous wording confusing. One last cc/ to @nodejs/build as well.

I don't think this needs to be on the ctc-agenda any more though.

[rvagg]

love it 👍

[Trott]

Seems like perhaps this ought to also be stated in the README or somewhere else that someone downloading a binary might see it. Ref: #14182

[gibfahn]

I think supported platforms should be on the download page of the website.