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] > >> > > >> > > >> > > >
