Strategy discussion for Post Base Image EOL

[unacceptable]

Description

There seems to be a gap in the availability of MariaDB versions 5.5.65 to 5.5.68 on Docker Hub. This issue appears to be linked to the removal of the 5.5 directory following the EOL of Ubuntu Trusty, as seen in PR #247.

Concern

The removal of support for an OS version (Ubuntu Trusty in this case) seems to have led to the unintended consequence of also removing access to certain MariaDB versions. Ideally, MariaDB versions should be maintained independently of the underlying OS versions, especially for critical security patches or minor updates that follow an OS's EOL.

Suggestion

1. Decouple MariaDB Versions from OS Versions: Even when the base OS reaches EOL, maintain Docker images for MariaDB versions that are still within their support period. This could involve updating the Dockerfile to use a newer base image.
2. Clear Policy for EOL Versions: Establish and document a clear policy regarding how MariaDB Docker images will be managed post base image EOL. This would help contributitors to understand transitions and maintaining security compliance.

Conclusion

While the missing 5.5.x versions do not require action, considering this scenario for future base image EOL status and establishing a clear strategy for future scenarios would be highly beneficial.

[grooverdan]

I'll try to clarify a few things there and see if anything is missed.

• The gap, before my time, was probably just the Docker Library people didn't notice or get time to do those updated, but got to it at the last release of 5.5.{68}. Its not directly related to Trusty removal.
• The github repo on the currently master branch, is the active version at the time.
• The currently supported versions are from this where the GitCommit is what is released.
• Rebuilds of 'currently supported' happen on when the OS base is updated - ref - and its history is recorded. These are build on the same GitCommit.
• So 10.11.5, the previous release, is no longer updated when its base OS (jammy) updates.

So Jammy EOL is April 2027 and MariaDB 10.11, end of maintaince 16 Feb 2028. 10.6 on Focal also exceeds the 10.6 maintenance date by a year.

You're right, I had not looked at this closely. As such I'm open to suggestions.

My current thoughts are:

• A release that goes GA (stable) should be consistent in its base image for its life, (which is why 10.6 is still on focal).
• A GA supported MariaDB should always be available
• Since we've got tags that include the base image 10.11-jammy, there's nothing preventing a 10.11-mantic to be released as well, so we offer a stable base for those that want it, and a security updated for those that don't.
• Following this pattern, where the distro EOL has occurred, tags without a distro name like 10.11 should adopt the non-EOL distro version as well.

So once a distro goes EOL, I expect the Docker Library Manifest to look like (release number made up):

Tags: 10.11.16-jammy, 10.11-jammy, 10-jammy
Architectures: amd64, arm64v8, ppc64le, s390x
GitCommit: b1fff513e7b7d015c5cfb2d91ffc24d903d33434
Directory: 10.11-jammy

Tags: 10.11.16-mantic, 10.11-mantic, 10-mantic, 10.11.16, 10.11, 10
Architectures: amd64, arm64v8, ppc64le, s390x
GitCommit: b1fff513e7b7d015c5cfb2d91ffc24d903d33434
Directory: 10.11

So the 10.11-jammy will have jammy as a base. Other tags will have latest stable OS as base.

Questions

• at what point to start making new-OS available? Probably waiting until the previous version is EOL is too long, and doesn't leave users much opportunity to test the new version.
• So while a OS (e.g. jammy) is not EOL, the release could look like the following to allow early testing?

Tags: 10.11.14-jammy, 10.11-jammy, 10-jammy, 10.11.14, 10.11, 10 
Architectures: amd64, arm64v8, ppc64le, s390x
GitCommit: b1fff513e7b7d015c5cfb2d91ffc24d903d33434
Directory: 10.11-jammy

Tags: 10.11.14-mantic, 10.11-mantic, 10-mantic
Architectures: amd64, arm64v8, ppc64le, s390x
GitCommit: b1fff513e7b7d015c5cfb2d91ffc24d903d33434
Directory: 10.11

Having a version on an EOL jammy sounds plausibility violating some best practices that Docker Official Images is meant to promote (despite its stability), so @tianon @yosifkit , is using an EOL base going to be allowed or not? Any other suggestions?

[tianon]

❤️

Using an EOL base for an extended period of time is not going to be allowed (if the time period is short, like EOL of the base in Jan and EOL of the software in Feb, we've been known to relax that a bit).

How we typically handle this in images we maintain is by maxing out at two supported versions per distro (so Debian stable + oldstable + Alpine latest + latest-1 in most of our images) and make sure to have explicit aliases as you've described (X.Y-bookworm, X.Y-bullseye, X.Y-alpine3.19, X.Y-alpine3.18). We then typically have "latest" or the unaliased tags follow the latest distro release actively unless there's a major (known) issue like docker-library/postgres#582 (and we handled that one by not updating the "latest" aliases and eventually removing those aliases completely from the supported set, once Buster went EOL).

I would caution against doing too much with non-LTS versions of Ubuntu (since they're more likely to have churn/breakage), but YMMV and obviously if you're doing the testing and that's the distro version that's the "most supported" upstream, then by all means we defer to your experience/support (in other words, this bit's firmly in the "suggestions" category, not "requirements"). 👍 ❤️

Hopefully something in my rambling here is helpful? 😅

[grooverdan]

Yep, that works out well.

Definitely going to be sticking with LTS, just don't have the time for churn (and generally little gain).

I missed the fact we drop MariaDB packages ones when the end of Ubuntu standard 5 years support happens. Extending this for 1 more year might not be a big issue. And we'll start doing multiple bases before EOL of the distro base so there's the option of pre-testing.

@unacceptable, so I'll write this up to some policy document. Anything you particularly think is particularly worth doing/emphasising around the distro EOL LTS (or standard support), do mention it.

[grooverdan]

Note: going back to a yearly LTS model - https://mariadb.org/adjusting-release-model/

The impact of this is with Ubuntu and MariaDB both being 5 year LTS support they the base image should stay constant for the entire length of support of the MariaDB version that had the original GA release. That's the plan anyway.

[grooverdan]

So I'm slack and didn't get to writing the policy statement (yet - PRs welcome), but per above commits being the EOL for ubuntu 2004 the 10.6 image is still on Ubuntu 20.04 focal and there is a 10.6-jammy tag commit too for the one upcoming release.

The scripting/build things are setup to do this as required the base image approaches EOL, and if I'm more aware (:embarrassed:) it might actually occur for more than one release cycle.