I agree that many users may be extending the image and would like to see some data if possible before making this call.
On Mon, Oct 12, 2026 at 3:56 PM Vikram Koka <[email protected]> wrote: > Hmm, what data do we have on the use of our production images? > > For example for 3.3 vs. other versions over the last year? > > On Mon, Oct 12, 2026 at 4:09 AM Jarek Potiuk <[email protected]> wrote: > >> > 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. >> >> If we do not publish the legacy image, migration to 3.4 will be harder for >> a number of current users. In the past, there were issues where people >> used >> the image we published. >> Many users extend the image by adding their dependencies, which might >> cause >> issues. The same occurred when we migrated to Bookworm two years ago: >> libraries and dependencies change. Tools work a bit differently. >> >> But yes - we might not publish the image. We could simply tell people, as >> we have done in the past, that they can build their own image instead of >> us >> publishing it ourselves. I am totally open to that. >> >> J. >> >> On Mon, Oct 12, 2026 at 10:23 AM Ash Berlin-Taylor <[email protected]> >> wrote: >> >> > 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] >> > >> > >> >
