Update list of distros for Go 1.18

[thaJeztah]

I noticed that the go1.18 versions of the image contained older
distro versions;

• debian buster and stretch reached EOL
• alpine 3.14 is still supported, but is not the latest version,
  and I'm not sure if there's reasons to support the previous version

[thaJeztah]

YOLO; so, I guess I basically was wondering; what's the policy on doing builds for older distro-versions when a new version of the image is added? I (think) distro versions are not removed after a version of Go was added (which may include some older distro versions), but wondering "what is the matrix when new go versions are added?"

At a glance, I couldn't find it in the https://github.com/docker-library/faq, but perhaps I overlooked 😂

[tianon]

Normally for docker-library repos like this, we stick to strictly "the latest two" (so that'd be bullseye+buster and alpine 3.15+3.14) in order to try and control the added load of building from source. In this specific case, we have received repeated requests for Debian Stretch versions (given it has older glibc and thus can build binaries compatible with other Red Hat based distributions, if I understood correctly), and given that most of the Debian-based images are able to download upstream-released binaries, the added load of supporting them is very low, and Debian Stretch is technically still LTS supported (even if it's no longer supported by the release or security teams officially).

So in this case it was "the resource load is low and supporting them all unilaterally makes the maintainer burden slightly lighter" so it happens to win out that they're ~OK. 😅

(However, Alpine will definitely be capped at the most recent two versions, as it compiles from source for all supported architectures.)

[tianon]

(Somewhere, @yosifkit has a comment with a nice explanation of that policy we apply to other compiled-from-source repositories that he might be able to find later and link to 😇)

[yosifkit]

docker-library/php#504 was where we first made decisions about supporting more than one OS suite at a time (because of users broken by #131). I think the practice of keeping two suites/releases per distro has just evolved over time to fit users needs while trying to not overwhelm our build servers.

[tianon]

Gonna close this one for now, but happy to continue discussing! ❤️

[thaJeztah]

Oh, wow, for some reason I missed this in my notifications (let's blame "I left a tab open"). Thanks (as always) for your reply!

In this specific case, we have received repeated requests for Debian Stretch versions (given it has older glibc and thus can build binaries compatible with other Red Hat based distributions, if I understood correctly)

Ah, interesting, yes, the glibc case could make sense (I know in our builds, we just copy the go binaries into the target-platform base image for this 😅)

So in this case it was "the resource load is low and supporting them all unilaterally makes the maintainer burden slightly lighter" so it happens to win out that they're ~OK.

Yes, Golang is the "easy" one for this, not a lot of burden to make it work. My train of thought here was "should we nudge people towards <please use current distros>", but I didn't think about the glibc case etc.

I think the practice of keeping two suites/releases per distro has just evolved over time to fit users needs while trying to not overwhelm our build servers.

Ah, thanks! I wondered if there was a fixed "policy". But looks like that may be difficult to write-up globally as (based on the above) I guess it's hard to define a "global" policy as things may differ a bit depending on the situation.

Thanks both, you rule!