I’m +1 to just using latest Debian stable at the start of every minor release (I.e. 3.4.x will always be based on Debian 13)
I’m -5 to publishing the `-legacy` tag though. If someone wants that: write your own Dockerfile and build it yourself. Our prod image should not try to be everything to everyone. -ash > On 10 Oct 2026, at 11:02, Jarek Potiuk <[email protected]> wrote: > > Hello everyone, > > Following the discussion [1], I'd like to call for lazy consensus on how > we build the CI and PROD images starting with Airflow 3.4.0: > > * 3.4.0: the CI image and the default PROD images are based on Docker > Hardened Images (Python prebuilt by Docker) on Debian 13 "trixie". > The base images are mirrored to ghcr.io/apache/airflow/base/python, > so building our images needs no registry credentials. > > * 3.4.x: we still publish PROD images built the current way (Python > compiled from sources by us on Debian 12 "bookworm"), but only under a > new "-legacy" tag suffix (e.g. apache/airflow:3.4.0-python3.12-legacy), > with a deprecation warning printed by the entrypoint. > > * 3.5.0: we drop the legacy images and bookworm entirely. > > * Testing: legacy images are not built in PRs or canary builds. A weekly > scheduled job on main builds them and runs the PROD image checks, and > they are fully built and tested on the v3-4-test branch and before > every 3.4.x release. > > The implementation is in https://github.com/apache/airflow/pull/73038. > Breeze can build either flavor ("--image-flavor hardened|legacy", > "--debian-version trixie|bookworm"); the CI image is always hardened > and trixie-based. > > Two follow-ups will occur after this one merged: > > * integrating -legacy in CI/release framework > * security: signing our images cryptographically > > The last point is the benefit of using hardened images: they are already > cryptographically signed, our images can build on top of that and > will be signed as well. with provenance information > so that our users will know the images were built using our secured > environment. I will implement this change by adding > a secure environment for all parts of the release process. > > The lazy consensus will last 72 hours, until 2026-10-13 18:00 UTC. If > there are no objections by then, I will consider it accepted. > > [1] https://lists.apache.org/thread/y0mlxsx36kzc84tn31q1kyl4rdvgv1xx > > J. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
