-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: note that EoL platforms are not supported #12672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, and it sounds like a good idea to me, but we might need larger buy in from the CTC.
@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 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. |
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. |
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:
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. |
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 |
@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. |
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:
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. |
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.1 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. 1 That's also an answer to @mhdawson's question of what "supported" means. |
Now that RHEL/CentOS 5 is end-of-life, update the baseline from linux >= 2.6.18 + glibc >= 2.5 to linux >= 2.6.32 + glibc >= 2.12. PR-URL: libuv#1324 Refs: nodejs/node#12672 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
@ljharb re: nodejs/build#688 (comment)
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:
We're happy to support people's use cases as long as it doesn't cause problems with our main platforms.
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. |
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. |
Adding the @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)? |
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:
|
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:
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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! |
I wonder if the language in the PR changed over the span of the discussion. What I see now is:
which does not mention Eol. I wonder if something like:
would be better. |
@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.
@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
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:
|
Does this statement mean that in LTS we support a distribution until is EoL and we can maintain the relative CI system going? |
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 |
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. |
Yes, if it's covered in the table below as a 1st or 2nd tier platform, then we should have CI cover for it.
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. |
This PR has plenty of LGTMs. How about we land it? |
@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)?
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. |
love it 👍 |
Add a note to clarify that any platform that is EoL will not be supported by Node.js. PR-URL: nodejs#12672 Fixes: nodejs/build#688 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Rod Vagg <rod@vagg.org>
Add a note to clarify that any platform that is EoL will not be supported by Node.js. PR-URL: #12672 Fixes: nodejs/build#688 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Rod Vagg <rod@vagg.org>
Add a note to clarify that any platform that is EoL will not be supported by Node.js. PR-URL: #12672 Fixes: nodejs/build#688 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Rod Vagg <rod@vagg.org>
@@ -33,6 +33,10 @@ Support is divided into three tiers: | |||
|
|||
### Supported platforms | |||
|
|||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think supported platforms should be on the download page of the website.
Add a note to clarify that any platform that is EoL will not be supported by Node.js. PR-URL: #12672 Fixes: nodejs/build#688 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Sam Roberts <vieuxtech@gmail.com> Reviewed-By: Rod Vagg <rod@vagg.org>
Add a note to clarify that any platform that is EoL will not be
supported by Node.js.
Fixes: nodejs/build#688
Checklist
Affected core subsystem(s)
doc, build