Jarek I like your proposal but I do have one comment. I think we should consider changing the behavior by - upgrading the minimum version when it causes issues and not by date. There is nothing fundamentally changing between May 2026 and Jun 2026 is it?. So my thought is to allow providers to continue to support airflow 2.11 as long as they don't cause issues. When they do cause issues the steward team can make the necessary adjustments and if no steward team is available then we just bump the version.
On Fri, Mar 6, 2026 at 11:48 PM Vikram Koka via dev <[email protected]> wrote: > Jarek, > > I really like the approach you have proposed here. > +1 to that. > > Vikram > > > On Fri, Mar 6, 2026 at 1:42 PM Kaxil Naik <[email protected]> wrote: > > > I like your idea Jarek > > > > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <[email protected]> wrote: > > > > > I am torn. > > > > > > I think it really depends on the effort required for the community to > > > maintain it. First of all I do not believe the list of blockers is > > serious > > > and strong enough to warrant it. As far as I know there is one > important > > > celery acknowledgment / timeout issue - that I looked into this > yesterday > > > with Jens, but I think there are already some good findings. This seems > > to > > > be a matter of documentation + possibly some code fix. > > > > > > However, I also hear and understand that some users will take more time > > to > > > migrate to Airflow 3. And google, Amazon teams (and other stewards) > might > > > want to provide new features for their services for a longer time even > > for > > > Airflow 2. And that's a valid ask. > > > > > > However, there are two things that we - maintainers of Airflow—must > > > maintain: > > > > > > 1) CI / CD configuration where we run tests against older airflow > > versions > > > 2) Any code implementation in providers that needs to maintain > > > compatibility > > > > > > While I think (1) is a minor issue, (2) will become a heavy burden on > the > > > overall maintenance of all providers if we want to maintain support for > > > longer for all providers. And this is actually very cool that the > Google > > > team wants to keep the provider supported for longer..... > > > > > > And that gave me an idea. Why don't we ensure that (2) doesn't place an > > > undue burden on maintainers of "Airflow" and "other providers". > > > > > > I don't think we need an "all or nothing" decision here. In fact - > even > > > today the decision on which version of Airflow to support for each > > provider > > > is made "per provider." > > > And we have the new governance framework where providers have stewards. > > So, > > > let's leave the decision on which Airflow version to support "per > > provider" > > > and require the steward to keep the compatibility - i.e. commitment to > > have > > > (2) done. > > > > > > We can easily continue (1) as long as we run it only for providers that > > > support older versions. > > > > > > We can make those cases an exceptions, but only when the steward > commits > > to > > > maintaining point (2). Any issue, that causes failure for older > versions > > of > > > Airflow must be fixed by the steward team. The steward is responsible > for > > > fixing any issue raised regarding an older version of Airflow via a PR. > > > > > > If fixes and maintenance overhead are not addressed within a reasonable > > > time, we can always decide to bump the minimum airflow version. > > > > > > I think that since we already have the task-sdk/airflow separation, > this > > > will not impact the rest of the code and other providers. > > > > > > With the new registry - we can easily show and surface support for > > Airflow > > > versions and add filtering for it. > > > > > > My proposal is: > > > > > > * Stay with the originally agreed min-airflow version timeline as the > > > default > > > * Require a commitment from the steward to keep the minimum version > lower > > > for individual providers, as an exception, not the rule. Also, if a > > > provider depends on other providers, the other providers' tests should > > not > > > fail - even if they do not support oldversions of Airflow. The current > > test > > > suite assures this. > > > > > > My thinking is that PMC should never support any provider outside the > > > regular schedule and only when a steward explicitly commits to another > > > schedule. > > > > > > J. > > > > > > > > > > > > > > > On Fri, Mar 6, 2026 at 7:22 PM Michał Modras via dev < > > > [email protected]> > > > wrote: > > > > > > > +1 to Jens's points - even if they are covered, good to call them out > > > > explicitly > > > > > > > > On Fri, Mar 6, 2026 at 7:19 PM Elad Kalif <[email protected]> > wrote: > > > > > > > > > These exceptions are already covered in our policy. > > > > > Nothing changes about them. > > > > > - Python version support policy remains the same. > > > > > - Release managers can always make judgment call on the minimum > > > > > airflow version of a specific provider (just like we did for fab > and > > > > > others) > > > > > - Features that are dependent on Airflow 3.x will keep as is. No > > extra > > > > > work to make them work on 2.11.x > > > > > > > > > > On Fri, Mar 6, 2026 at 8:14 PM Jens Scheffler <[email protected] > > > > > > wrote: > > > > > > > > > > > Hi Elad, > > > > > > > > > > > > I think this is reasonable and I would support this with three > > > > > exceptions: > > > > > > > > > > > > * We should not keep Python (core) version support longer, so > as > > > soon > > > > > > as we drop for example 3.10 support this is also valid for > > > anybody > > > > > > still runnin old Airflow 2 with Python 3.10. > > > > > > * If for any reason some dependency needs to be bumped that > > breaks > > > > > > support we might need to exclude some providers from the > > support > > > > > > (Like we did for example for Edge). Focus should be on core > and > > > > > > heavy use providers (e.g. K8s). > > > > > > * Same yields for new features - if they are incompatible this > > > > reduces > > > > > > support only for potential subsets of providers, cool new > > > features > > > > > > might be only working on Airflow 3. > > > > > > > > > > > > Jens > > > > > > > > > > > > On 06.03.26 14:17, Elad Kalif wrote: > > > > > > > Hello community, > > > > > > > > > > > > > > As our policy > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/airflow/blob/main/PROVIDERS.rst#upgrading-minimum-supported-version-of-airflow > > > > > > > states: > > > > > > > > > > > > > > The default support timespan for the minimum version of Airflow > > > > (there > > > > > > >> could be justified exceptions) is that we increase the minimum > > > > Airflow > > > > > > >> version to the next MINOR release, when 12 months passed since > > the > > > > > first > > > > > > >> release for the MINOR version of Airflow. > > > > > > > > > > > > > > This means that in May 2026 providers will bulk change > > > > > > > minimum apache-airflow version from 2.11 to 3.1. Since this > > policy > > > > was > > > > > > > established on bumping minor versions I'd like to open a > > discussion > > > > > with > > > > > > > the community if we should keep the policy as is for major > > versions > > > > > > (2->3). > > > > > > > > > > > > > > Providers can continue to support 2.11 even after 2.11 reaches > > EOL. > > > > > > > > > > > > > > My thoughts is that we still have open issues that are marked > as > > > > > blocker > > > > > > > for users migration from 2 to 3: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/airflow/issues?q=is%3Aissue%20state%3Aopen%20label%3Apriority%3Aupgrade_to_airflow3 > > > > > > > thus some users were not able to use the 12 months to make the > > > > > upgrade. I > > > > > > > think we need to consider making an exception and keep > supporting > > > > 2.11 > > > > > in > > > > > > > providers for a while longer. > > > > > > > The impact is that users who need a bug fix of an operator in > > K8s, > > > > > google > > > > > > > or amazon won't be able to get the fixes unless they will apply > > it > > > > from > > > > > > > their side. While workarounds do exist I think we help users to > > > focus > > > > > on > > > > > > > migration rather than spending time on workarounds. > > > > > > > I think extending support by a few months is reasonable. > > > > > > > > > > > > > > My suggestion: > > > > > > > Extend support in providers for 2.11 till Aug 2026. > > > > > > > > > > > > > > Thanks, > > > > > > > Elad > > > > > > > > > > > > > > > > > > > > > >
