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