I would vote for option A. > 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).
Users may stall with migration if we publish legacy images, but without them, we take away from users the possibility to do gradual changes on environments. First Airflow version to 3.4 and after that separate modification to DHI-based image. I assume that many users can have different issues, and it may be hard for us to predict all of them; making that separation possible should: 1. make upgrading to 3.4.0 for users easier, which should mean quicker feedback (and adoption) 2. easier separation and debugging of potential problems in the environments thanks to separation of modifications introduced to the environments 3. users will have an easy path back in case of things not working after environment upgrade (no Airflow version revert needed) I think that if we do not publish legacy images, we will see slower adoption of the 3.4 version, which, I would say, is rather unwanted. The second part, which Jarek mentioned already, is stabilisation. This can be on users' side and on ours too. We already encountered a couple of issues with new images, and I would assume that we will encounter more. Having both images published, we will have some safeguard if things go bad with DHI. > - 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. We have to remember that these data will not be reliable and are missing context. Not reliable, because there are users who are using internal registries to which images from DockerHub are copied. We do not, and will not, have data on what is happening there. Missing context to what is mentioned already (no version specific, etc.) > DHI is relatively new, so in theory it'll become more stable as time goes on. I agree, but the question is how long it can potentially take. We don't know the answer to that question. It can be a month or a year. There is also one thing. Some users who are running Airflow may have a dedicated platform team for Airflow and some number of users. Having a possible split of business/platform change (Airflow version upgrade) and platform change (DHI) can make planning easier (not sure tho if we are looking at things like that 🤔, but I would consider organisational approach and people there too). I have nothing against dropping legacy with 3.5 release (at least now, it is hard to predict what situation will be in a couple months). Best, Przemek On 2026/11/02 12:13:02 Ash Berlin-Taylor via dev wrote: > Brain fart, sorry, I meant “which problems are these” but I have since seen > your reply in the thread where I proposed simplification. > > > On 2 Nov 2026, at 11:45, Jarek Potiuk <[email protected]> wrote: > > > > The ones we build on? > > > > Docker Hardened Images (Python images). Generally wdely accepted as a way > > how to keep your images as secure as possible (they are patching their > > images up to few times a day). > > > > They are freely available and free for commercial use - Apache 2.0 licensed > > (these are the community images we are using). > > > > They also have commercial FIPS compliant drop-in replacements, which people > > can use as base images when following our 'build your own image' recipe. > > > > This is a bonus because our users can easily achieve FIPS compliance and > > users often asked for it. So we do not have to provide it - they can pay > > Docker for access to those FIPS compliant replacement base images. > > > > More info: > > > > Hardened Images | Docker https://share.google/J7g1i0JXzdUGHkW6G > > > > J. > > > > > > > > > > > > > > On Mon, Nov 2, 2026, 12:22 Ash Berlin-Taylor via dev > > <[email protected]> > > wrote: > > > >> What images are these? > >> > >>> On 1 Nov 2026, at 22:06, Jarek Potiuk <[email protected]> wrote: > >>> > >>> Actually - after seeing the kind of issues we faced even after my last > >>> email 2 days ago -> the issues (and complexity of solutions) might be > >>> somewhat intimidating to our users > >>> > >>> I personally think we should provide a bridge for our users. > >>> > >>> While I **strongly** believe DHI approach is good and has strong security > >>> implications, some of my users for 3.4.* would prefer to use the > >> "original" > >>> setup. > >>> > >>> I am fine for 3.5 - to drop all kind of legacy images, but I think that > >>> might be to ""steep** change - and being able to just switch to `FROM > >>> apache/aifrlow:legacy-3.11` is an easy way to address all kinds of > >>> incompatibilities. > >>> > >>> If we got (and we did) 3 library compatibility issues that required a > >>> change in how the image uses the base DHI image - our users will have > >> even > >>> more of that - and they will reach out to us. > >>> > >>> Are we ready to handle our user's problems? > >>> > >>> For me - the easiest approach would be: > >>> > >>> * here are some general ways and you might follow it > >>> * but if you have no time/energy to follow it - the legacy image will > >> keep > >>> you running. > >>> > >>> I would always ask anyone who says "drop it": Are you ready to solve > >>> problems of our users if they see problems? > >>> > >>> My answer is: Yes - try to fix it following our vague instructions, if > >> you > >>> fail, use the legacy image for an easy fallback. > >>> > >>> What is the answer if we decide not to publish legacy image ? Ash, Jed? > >>> what would you answer to the users? (and I am not precluding any answer - > >>> we just have to remember that this should be the answer PMC is firmly > >>> behind, no matter who is answering it) > >>> > >>> On Fri, Oct 30, 2026 at 7:02 PM Jed Cunningham <[email protected] > >>> > >>> wrote: > >>> > >>>> I still lean toward B, myself. My take is that leaving C as an option > >>>> injects some uncertainty for both sides, and offering legacy flavors > >> just > >>>> kicks the can down the road. > >>>> > >>>> DHI is relatively new, so in theory it'll become more stable as time > >> goes > >>>> on. > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
