In my view: option C still incurs overhead. The Dockerfile is _2526_ lines. Every one of those lines carries maintenance and cognitive burden. In my view It should be about 100 lines at most. That is the complexity I am talking about when I say “should not try to be everything to everyone”. I’ll start a new thread about this.
But essentially option B and C are the same at this point on effort, so I am happy with either of these. -ash > On 24 Oct 2026, at 12:42, Jarek Potiuk <[email protected]> wrote: > > Hello everyone, > > As summarized in the [RESULT] of the hardened-images lazy consensus > [1], we agreed that starting in 3.4.0, CI and default PROD images will > be based on Docker Hardened Images on Debian 13 "trixie" (#73038 is > merged). > > One question remains open: should we also publish PROD images built > the old way (Python compiled from sources on Debian 12 "bookworm") > under a -legacy tag suffix for the 3.4.x line (e.g., > apache/airflow:3.4.0-python3.12-legacy)? > > Context & Trade-offs > > Many users extend our base images with custom system and Python > dependencies. Upgrading the base OS changes library versions and tool > behavior, which may break some extended images. A -legacy tag allows > users to upgrade Airflow first and the OS later. However, maintaining > this requires building, testing, and releasing a second set of images > for every 3.4.x release, with the risk that users stall migration > until 3.5.0 (when bookworm support is dropped entirely). > > Options > > - A. Publish -legacy images for all 3.4.x releases with a > deprecation warning in the entrypoint (original proposal). > - B. Do not publish them. Users requiring bookworm can build images > locally, as #73038 keeps this flavor buildable (e.g., via breeze > prod-image build --image-flavor legacy --debian-version bookworm or > Dockerfile build args), which we will document. > - C. Start with B, and only publish -legacy images if 3.4.0 users > report significant breakage that cannot easily be resolved. > > Feedback so far > > - Ash prefers B ("our prod image should not try to be everything to > everyone"). > - Vikram suggested checking usage data first. However, Docker Hub > only provides total pull counts (~14M in September), not > version-specific or usage breakdown, so community reports remain our > primary data source. > > Recommendation > > My preference is C: it incurs no overhead now, keeps the option open, > and feedback from 3.4.0 betas/RCs will quickly show if the switch > causes issues. > > I would like to settle this before 3.4.0. If we reach consensus around > one option, I will follow up with a [LAZY CONSENSUS] thread. > > [1] https://lists.apache.org/thread/h0sxvd5g4drxfrph35dvlrk46zomsk0y > > Jarek > > --------------------------------------------------------------------- > 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]
