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