Also - the https://github.com/apache/airflow/pull/73038 is green and ready to review/merge. It keeps both the old way of building images and the new hardened images. We can still choose (that will be a follow-up) which images to release. I hope we can reach a consensus on whether to release the -legacy one (it could have another name as well), so - for now I think merging this one and getting consensus on hardened images would be useful, allowing for more voices and discussion afterward.
J. On Tue, Oct 13, 2026 at 10:09 AM Jarek Potiuk <[email protected]> wrote: > It's a vanity metrics of course but we had 14M downloads in September as > reported by Dockerhub. Like for other things we do not have more detailed > data unfortunately. > > J. > > On Mon, Oct 12, 2026, 23:58 Vikram Koka via dev <[email protected]> > wrote: > >> 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] >> >> > >> >> > >> >> >> > >> >
