Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@AkihiroSuda @thaJeztah Wanted to know your thoughts on this change. Is there any other distro for which we were holding back other than CentOS 7 to maintain glibc compatilbity.

Hm.. good one; I don't know what distros we "officially' support with the generic builds, but it's worth checking what versions of glibc come with the "expected" ones;

• Debian 11 Bullseye (old stable), Debian 12 Bookworm (stable)
• Ubuntu 20.04, 22.04 (previous LTS releases that didn't reach EOL)
• RHEL 8 (?) and "similar" (Rocky Linux 8?) (CentOS 7 and 8 are EOL)

From what I can see on our (docker's package repository) installations, looks like Focal (20.04) is still most popular with ~10 Million downloads a month; Jammy (22.04) second, and Noble (24.04) last. But of course not sure how it's distributed for the packages from this repository.

Looks like we should continue using ubuntu-20.04?

I think it all evolves around "what do we promise these packages to be?", but not sure how much of this can be changed.

I personally think it may be advertise that the project provides "generic", distro-agnostic builds; they allow you to get early / immediate access to binaries for testing when the project does a release. For other scenarios; if you need packaged versions specific to your distro-version; use the version packaged by your distro, the packages provided as part of docker's package repository, or ... (I think there was work elsewhere to provide distro-specific packages?).

In all honesty, I'm still wondering whether it was a good choice to provide binary release as part of this repository; binaries through GitHub releases work OK(ish) for static binaries ("just grab one for your architecture, and Go"), but get complicated fast for other kind of binaries; now the project would have to maintain a large matrix of possible variants, and even for the static binaries, conflating packaging and code-releases becomes a burden (e.g. Go has a vulnerability, and now the project needs to do a new release to provide new binaries rebuilt with the new Go version).

Packaging can be a beast (doing it right can be a huge pain when taking different distros; some with their own subtle conventions into account), and I'm somewhat wondering if (perhaps v2.0 is a good opportunity) it should be a separate initiative / project.

Considering the usage of containerd in focal , I think we can still stick to using ubuntu-20 for release binaries.

And around releasing binaries as part of the github releases, I dont have a strong opinion on removing that, because consumers may want to try out a different version rather than the one packaged and made available with the distro. So this github release is the only reliable source to download binaries of those versions.

Since ubuntu-20 will be removed from github actions. Ref we should revisit this.

@thaJeztah Is it possible to get newer data of installed versions similar to #10405 (comment) so that we can decide on how to proceed further.

cc: @AkihiroSuda

Looks like it's a tie between Focal (20.04) and Jammy (22.04) now; Noble (24.04) is far behind on those (followed by Bionic (18.04))

Derp; and including the screenshot