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