Repository navigation
Generate Images for multiple versions of Alpine #473
Description
Activity
I like this, that way older node images can opt-in to newer alpine bases.
@nodejs/docker thoughts?
I like this too and it's an approach Docker is using for the images they maintain.
How does the different Alpine versions lign up with Node.js LTS versions? Do we risk ending up with unmaintained Alpine versions for maintained LTS versions of Node.js if we do this?
Do we risk ending up with unmaintained Alpine versions for maintained LTS versions of Node.js if we do this?
If anything, the risk is lower than the current status (which has alpine 3.4 for node 6). If we do this, people on node 6 (like we are at work, although we'll go to 8 as soon as it's LTS) can still use alpine 3.6
I think it's a mistake to couple the OS version with the LTS status of the node.js release. The OS that it's delivered on doesn't change that contract and providing multiple versions with different operating systems puts the decision in the user's hands. The issue I see now is that we either take what's currently offered, alpine-3.4 with the LTS node for instance or building the image ourselves.
That is only partly correct. LTS stands for Long Term Support and the contract as it reads to users is a stable and supported version. If we put an LTS version of Node.js on top of an operating system that stops receiving critical security patches during the software's lifetime it is not strictly long term support.
Understood, but LTS is talking about the node.js release, not the underlying OS. By making several versions of the OS available, you're allowing the user to decide. It's not saying the whole docker image is LTS, it's simply stating that you have an LTS version of node.js on a specific OS.
Agreed! It looks like Alpine Linux does not have any LTS versions, each stable version is supported for 2 years according to this document. We could include these support dates along with different tag information.
Reacted by Eric RutherfordAny plans to go with alpine 3.7 for node 8 ?
I would do the change, but there is no guide how to have multiple versions of alpineIs alpine the only OS we would do this for?
I think we should have sub folder in the alpine folders with alpine version and adapt the update script to use the same node js version logic for the alpine version.
One problem though I see with that is it's possible that if we maintain multiple alpine versions is that the build will stop working because the alpine build is over 50% of the build time. If we build two or more, we are likely to hit the max build time
Yeah, ideally if we start adding multiple Alpine versions we'd want to have native node.js musl/alpine binaries rather than building from source each time.
4 remaining items
The ci build times are a big part of it. It adds to how long it takes for the PR to land on the official hub repo, and then for the images to be released. Adding images for each supported release of Alpine would add a pretty significant amount of time to the ci-run.
- added 12 commits that reference this issue
on May 10, 2018 Closing per #725 (comment)
Rather than maintain multiple versions of Alpine we're just going to update to the latest available version when we push out Node.js updates. The current alpine image variants will all eventually be at 3.7
Reacted by Kishan B
Right now it seems as though each node release is tied to a specific release of Alpine (for the Alpine tags). I wonder if it'd be feasible to offer a default tag
6.11.1-alpine, but also tags mapped to specific versions of alpine6.11.1-alpine3.6,6.11.1-alpine3.4, etc. similar to what the official golang docker images are doing.