> I agree with that and also, I have a small concern too. Wouldn't that be too big support drop at one time (drop of version 1 and almost whole version 2)? I was thinking that maybe it would be better to drop only support for version 1 after release of 1.19.0. Then drop version 2 despite 2.11 (something like bridge version between Airflow 2 and 3), and after that drop of 2.11 entirely. What do you think?
I am not too worried. We are **just** stopping supporting 2.10 for providers (vote in progress) and WE WANT people to move to 2.11 if they use 2, and we definitely do not want them to use 1. If the users want to have any "new" features from the chart they are still able to patch previous versions, Charts are just a bunch of yaml templates. Besides we have even no **idea** if the chart (and certainly not any new features) still support Airflow 1, nor Airflow 2 because we simply don't test it with those versions- we have some basic tests which we **hope** works but I doubt any one from the maintainers actually run the chart with Airflow 1 or Airflow 2.0-2.7 for - basically - years. I think a better service for the users will be to follow the same pattern we have for providers and adjust our docker-compose e2e tests to run tests for all the "supported" minor versions (like we do with providers). J. On Thu, Nov 27, 2025 at 8:33 PM Przemysław Mirowski <[email protected]> wrote: > > So Jed and me wanted to drop exactly the same topic and propose that we > make a release policy with the Helm chart matching the rest of the SW > release cycle, meaning to release 1.19 as next version and after this drop > support For Airflow <= 2.10. Next year then drop support for Airflow <3. > > I agree with that and also, I have a small concern too. Wouldn't that be > too big support drop at one time (drop of version 1 and almost whole > version 2)? I was thinking that maybe it would be better to drop only > support for version 1 after release of 1.19.0. Then drop version 2 despite > 2.11 (something like bridge version between Airflow 2 and 3), and after > that drop of 2.11 entirely. What do you think? > > ________________________________ > From: Jens Scheffler <[email protected]> > Sent: 26 November 2025 20:20 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Removal of Airflow 1 support from official Helm > Chart > > Hi, > > oh, you catched a topic that I also wanted to drop together with Jed to > the devlist. > > So far the Helm chart never made deprecations for old Airflow versions. > But we stop supporting Airflow-Versions based on release date, so for > example with providers release (=tomorrow) we will stop releasing > providers for Airflow 2.10 and will only further support Airflow 2.11. > Same like with Python, we dropped support for Python 3.9 and require > Python 3.10++ > > So Jed and me wanted to drop exactly the same topic and propose that we > make a release policy with the Helm chart matching the rest of the SW > release cycle, meaning to release 1.19 as next version and after this > drop support For Airflow <= 2.10. Next year then drop support for > Airflow <3. > > Discussion and other opinions open! > > Jens > > On 11/26/25 19:25, Przemysław Mirowski wrote: > > Dear Airflow Community, > > I would like to ask your opinion on removing support for Airflow 1 from > official Helm Chart. > > Airflow 1 is unsupported for many years now and I think having it in the > Helm Chart introduces more complexity. Furthermore it raises the threshold > for new contributors, cause it general all of the changes in the Helm Chart > now should support Airflow in version 1, 2 and 3. > > Before dev list I created a discussion topic on GitHub - Removal of > Airflow 1 support from official Helm Chart · apache/airflow · Discussion > #58691<https://github.com/apache/airflow/discussions/58691>. > > Best Regards, > > P.M. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
