Update from Node 8.11 to the latest 8.x (8.11 is no longer supported)

[tianon]

See also https://travis-ci.org/docker-library/official-images/builds/449066913 (from docker-library/official-images#5020).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[lag-linaro]

LGTM

[lag-linaro]

@tianon how did you test this?

[sampaiodiego]

@tianon Meteor does not recommend using 8.11 right now, so we should stick with Node 8.11.x : https://github.com/meteor/meteor/blob/devel/History.md#changes-3

why is 8.11 no longer supported? any way we can still use it? Maybe forcing to 8.11.4?

[sampaiodiego]

seems we'll have to wait for Meteor 1.8.1 with Node 8.15: meteor/meteor#10248

we cannot update Node version right now because there are many reports (meteor/meteor#10216) about CPU issues with Meteor 1.8.0.

[sampaiodiego]

Once Meteor release its version 1.8.1 we start using a new Node version, but we still have to stick with Meteor'd recommended Node version, instead of latest.

[sampaiodiego]

Suggested change

	FROM node:8-slim
	FROM node:8.15-slim

[tianon]

why is 8.11 no longer supported? any way we can still use it? Maybe forcing to 8.11.4?

Not sure -- that'd be a question for the node image maintainers (and possibly even the Node.js core maintainer group). They only officially support the latest of each major series (6.x, 8.x, 10.x, and 11.x).

[geekgonecrazy]

Am I understanding that they actually untag their old images when they release another one?

So the only way we could keep from breaking under us is probably to switch this to our own base image like the other image uses I guess? A bit surprised that this is the first time this has happened to us. Meteor used to be really behind.

[sampaiodiego]

Am I understanding that they actually untag their old images when they release another one?

@geekgonecrazy nope. from what I get, there is a list of supported tags on https://hub.docker.com/_/node which is the same list you can found here: https://github.com/docker-library/official-images/blob/master/library/node

so any official image can only depend on other official images and its supported tags (is that right @tianon ?) that's why my PR failed: https://travis-ci.org/docker-library/official-images/builds/481461250#L630

[sampaiodiego]

I'm surprised as well how this didn't affected us earlier. I don't know what we would do in case we didn't have other image to keep updated, we would stuck with this very old version until Meteor updates Node to a supported version 🤔

[sampaiodiego]

just thought we could actually start from debian:jessie (instead of node:8-slim) and install the node version we need by ourselves (pretty much as our base image does)

what do you guys think? we would double the Dockerfile size but at least would have the Rocket.Chat version updated.

[geekgonecrazy]

Going to try and get this into our main repo as started discussing in #61

I don't see why not to just use our base image?

[sampaiodiego]

I don't see why not to just use our base image?

@geekgonecrazy see https://github.com/docker-library/official-images#repeatability

No official images can be derived from, or depend on, non-official images

[tianon]

It's definitely concerning to me that Node.js 8.x releases have had breaking changes -- is there an issue filed with the Node.js team where that was discussed?

It's my understanding that Node.js 8.x is supposed to be like a minor release in semver terms; from https://github.com/nodejs/Release:

Once a major version enters LTS coverage, new features (semver-minor) may only be landed with consent of the Release working group. No semver-major changes other than those required for critical security fixes may be landed.

Changes in an LTS-covered major version are limited to:

1. Bug fixes;
2. Security updates;
3. Non-semver-major npm updates;
4. Relevant documentation updates;
5. Certain performance improvements where the risk of breaking existing
   applications is minimal;
6. Changes that introduce large amount of code churn where the risk of breaking
   existing applications is low and where the change in question may
   significantly ease the ability to backport future changes due to the
   reduction in diff noise.

I have to imagine they'd be very keen to know that a major project like Meteor is seeing issues with a newer 8.x release. 😓 😞

The only https://github.com/nodejs ticket I can find in either of those issue threads is nodejs/node#21021 (mentioned at meteor/meteor#10216 (comment)), but it doesn't seem to directly be the Meteor issue.

Do they have a proper escalation/notification process for letting them know about potential LTS breaking changes? (Possibly just issues on https://github.com/nodejs/node?)

[geekgonecrazy]

Please add what ever additional information you guys can think of: https://github.com/nodejs/node/issues/25617 nodejs/docker-node#978

[Sing-Li]

@tianon Is there anything you can suggest that will allow us to move this forward.

Being caught between the three-way policies rally (docker, node, meteor) - our official container is now three months out of sync with current version / development. We are forced to divert active users to other non-official container releases in the mean time 😞

[geekgonecrazy]

This less than pretty PR should get it working... I think: #68

[geekgonecrazy]

Going to go ahead and close this one out. Thanks!