[DISCUSS] Providers support for Airflow 2.11

[Elad Kalif <el...@apache.org>]

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

Re: [DISCUSS] Providers support for Airflow 2.11

[Jarek Potiuk <ja...@potiuk.com>]

I have been thinking about it... And I have one idea and observation from
the last few days that changed my mind a bit.

Possibly we should **indeed** just listen to what our users have to say,
and only then make a decision.

I still think my biggest problem here is making things more complex and
difficult for maintainers. This is why "complicating" the whole process
(Elad's latest proposal) is pretty much a no-go when I consider the
consequences it will have: increased burden, communication issues, problems
with release management, coordination between various providers. If no one
is willing to commit to doing it, that is a decision we should not make.

However the actual support date for 2.11 and providers (and Airflow 2 in
general) is a different matter. While I see no reason to move the date,
perhaps we should hear from our users on this. However I do not think any
"abstract" arguments here - or even a list of open issues marked as
blockers is enough here.

I think what we really need are stories from users who tried to migrate to
Airflow 3, encountered significant problems, and could tell us what is
**really** missing in Airflow 3 so that we can - with some degree of
certainty say  - "yes you can migrate, here is the process and you will not
face a disaster".

Jens's story—which he partially told here and partially on Slack over the
last few days—actually made me more open to moving the date further, but
under one condition: that we as a community, gather information on what is
**really** still problematic in Airflow 3 that makes migration very
difficult. We've already heard several complaints, some of them captured in
issues, but with a number of issues we have now, we might have missed
important things still not working. And fixed a number of them, and we hear
people migrating to 3.1.0 or 3.0.5 complaining that things ae not working -
which we often put in the "try the latest 3.* version first.

But Jen's  story for me is mostly a very strong "yellow" light, telling us
we are indeed not ready yet to drop support for 2.11.

We have someone who knows Airflow inside and out, who is a real user,
running Airflow at scale and migrated to 3.1.7 - Yet, Airflow's reputation
at Bosch suffered. Jens and his team (more than 3 people from what I hear)
spent over 12 hours a day last week fighting the issue, managing internal
escalations and generally protecting Airflow's reputation through heroic
effort.

This is VERY BAD. This actually means that we are probably not ready yet.

But arbitrarily moving the date does not solve the issue. If we don't spend
time and effort first identifying the issues we have and second solving the
issues that make us "not ready," moving the date only buys a little time.
It doesn't solve the underlying problem: migrating to Airflow 3 is hard and
has many traps.

My proposal here is to use the community feedback here. I am sure this dev
list has many users who are "bolder" and have tried migrating to Airflow 3.
And they know Airflow well and can describe their issues - without getting
into the weeds of us "not believing they did everything right." I am
talking about larger users with problems at scale—issues we did not have a
chance to test ourselves so far and only appears when you actually try to
migrate in production.

I would really encourage users like Jens to share their stories here and
tell us what **really** we are missing. Then we could also build an actual
list of things that we—maintainers—need to fix before calling it a day for
Airflow 2, rather than waiting for our users to contribute them.

Maybe we can repurpose this thread into a "war stories" thread where
engaged and knowledgeable users will share the real problems they
encountered during migration?  That could allow us to make the right
decisions about the dates, but only if we commit to fixing those most
important pain points before that date to ensure success.

My ask to anyone looking at that thread is this: if you are a user and have
a bad story from migrating to Airflow 3, please share it here.

J.



On Mon, Mar 9, 2026 at 7:41 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> I'd also really like to see what others think here. I personally think
> the current scheme is really good (in terms of process). Having
> predictable dates and gently pushing people to upgrade is good. Having
> stewards particularly interested in longer support with their
> providers and committing to it is, I think a good and natural
> extension of the new provider governance we introduced. And I believe
> I've posted enough arguments, to show that a scheme where each
> provider sets its own (unpredictable) time for dropping support is
> quite problematic.
>
> However, when it comes to the actual timing, we drop new provider
> releases for 2.11. I would love to hear other voices on this topic.
>
> I think what we are discussing here is not a "mature" product vision.
> We have a mature product. That's undeniable. Whether it's 12 or 24
> months makes little difference - just by providing compatibility,
> testing it and releasing providers for older Airflow versions, we
> already show that we actually care. Remember in Airflow 1, providers
> were really part of Airflow, and you had to upgrade to the latest
> Airflow to use any new provider features and bugfixes. Yes - you had
> to upgrade to latest version of Airflow if you wanted to have this one
> bugfix for http Operator or Hook. Even Airflow 1 was a really
> "serious" product. So we are already **very** mature here. We not only
> release those providers, but for about a year and a half now, we have
> also run full compatibility tests with older Airflow versions. That's
> already a lot to demand from essentially an open-source product.
>
> I think what we are really talking about here is trading maintainer
> effort against user effort to keep up with new changes. I am not sure
> if "mature" platform means long support - and how long —especially
> since we aren't dropping "support" but rather "maintenance." And
> really it's about being able to use some new features we release in
> the providers. As a community, we do not have "support", really. We
> intend (though we don't commit—we bumped the minimum version for
> several providers sooner than 12 months for various reasons) to
> maintain things (mostly voluntarily) for a specific time.
>
> So I would really love to hear - from the wider community. Is it a
> major issue that the latest providers cannot be installed for Airflow
> 2? Is it really a major inconvenience for them to backport the most
> important features, either individually or through service providers,
> if they really want to do so? How does it compare to the increased
> maintenance effort required for a longer duration by maintainers and
> contributors who must deal with backward compatibility? (I helped
> several contributors who were completely lost on how to run and fix
> compatibility issues—the pain is real.)
>
> J.
>
> On Mon, Mar 9, 2026 at 7:04 PM Michał Modras via dev
> <de...@airflow.apache.org> wrote:
> >
> > Personally, I'm fine with deprecations based on date or version. In this
> > particular case, it is not really about Airflow 2.11, but rather Airflow
> 2
> > as a whole major version. Which is still the most popular Airflow version
> > adopted across the industry. Given all the changes Airflow 3 brings, 2.11
> > deserves a longer compatibility period for providers than a random
> Airflow
> > 2 minor version.
> >
> > In my view, the goal is clear - exactly as described, be gentle to the
> > users, and do not push them too strongly to Airflow 3, regardless of how
> > much we want everyone on the latest version. Across the industry,
> > migrations take time. Sometimes a long time. We should build an image of
> > Airflow as a mature platform, that does not drop support for hundreds or
> > thousands of integrations across multiple providers in 12 months since a
> > public launch of a major version - it is not a long time in the industry.
> >
> > On Sun, Mar 8, 2026 at 2:22 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > > I think we should consider changing the behavior by - upgrading the
> > > minimum version when it causes issues, not by date.
> > >
> > > Question: What goal do you want to achieve this way? I think we should
> > > generally optimize our processes based on the goal we want to achieve.
> > >
> > > I can see one goal it can achieve: Keeping our users from migrating to
> > > Airflow 3. Which for me, personallly, is a "non-goal." But maybe there
> are
> > > others I do not see..
> > >
> > > I think that would a) complicate things for us, b) prevent us from
> making
> > > bold changes, heavy refactors and adding some "cross-cutting concerns"
> > > across the providers, and c) lose the implicit property of our
> "provider
> > > min-version support"—which incentivizes our users to migrate to newer
> > > airflow versions. Yes, one of the reasons we have a minimum airflow
> version
> > > policy is to gently encourage our users to migrate to a newer version
> of
> > > Airflow. This was a deliberate goal when we introduced it. We wanted
> users
> > > who need to use provider X's new feature to migrate to a newer version
> of
> > > Airflow.  This remains a goal of this setup today.
> > >
> > > Removing min-airflow-version across the board benefits both
> maintainers and
> > > the product. Namely, we can (and have in the past) make changes across
> all
> > > providers, which generally simplified maintaining the code across
> them.  We
> > > are now starting to implement some common patterns that we want to use
> > > across all providers—AIP-99—which essentially elevates the importance
> of
> > > Hooks and allows us to make essentially all of our integrations
> LLM-native.
> > > And it's just the beginning. Most of such "across all provider"
> changes are
> > > done by someone who does not know well those providers and this is
> already
> > > big difficulty. If you add to the mix that for this provider, you would
> > > have to make sure compatibility with 2.11+ and for that provider
> > > compatibility with 3.2+ and for another provider for 3.1+, and you will
> > > have to know all that and effectively learn some test patterns and
> > > conditional cases for all providers adds quite an effort to any such
> > > change.  If a steward commits to maintaining the old version, they will
> > > bear the burden of implementing necessary changes to ensure
> > > back-compatibility in their provider when we make such changes. They
> are
> > > the experts, they know best how to address some problems - and author
> of a
> > > "new cross cutting idea" will not have to worry about that (too much)
> - or
> > > will get help from the steward.
> > >
> > > Also, maintaining compatibility is a burden today. Ask many of the
> > > contributors (I helped many of them) who had to ensure their changes
> work
> > > with compatibility tests - this is a significant burden. If you want to
> > > ensure that changes in Provider A work with Airflow 2.11. 3.0. 3.1 -
> You
> > > must run all tests with it, add conditional code, make some tests
> > > conditional. Sometimes you need to copy&paste code from old versions,
> or
> > > add new code to "common.compat". Those require extra effort. If we
> > > maintainsupport for older versions for longer time, those problems will
> > > only worsen—and quickly.
> > >
> > > These are the goals of the current implementation:
> > >
> > > 1) Address the need for some stewards to keep their integration
> available
> > > in older versions
> > > 2) Gently encourage users to migrate to the newer version of Airflow
> when
> > > they need new features from providers
> > > 3) Allow us to make bolder changes across many providers
> > > 4) Limit the burden on maintainers to maintain compatibility.
> > > 5) Predictability for the users
> > >
> > > Also note that 2) is very "soft." It blocks nothing; it deliberately
> moves
> > > the burden from maintainers to users. Nothing prevents users of Airflow
> > > 2.11 from keeping the latest version of the Http Provider that is
> > > compatible with 2.11.  There is also nothing to prevent them from
> > > backporting any of new changes that we implement to their
> Dags/Libraries if
> > > they want to use it. This is open-source software, and the users can
> take
> > > any new Http Hook implementation, adapt it to work on 2.11 and use it
> > > internally in their Dags. The big difference is that the responsibility
> > > lies with "them," not with maintainers. I think it's actually fair to
> > > offload some of the difficulty with supporting old versions on the
> users.
> > > Since migrating is their choice, we can expect them to make the
> necessary
> > > effort if they want to use new features. I see no issue with it, I
> even see
> > > it as a great incentive scheme - with the current setup:
> > >
> > > The longer a user delays migration the more costly it becomes if they
> want
> > > to keep up with the provider's latest features. At some point, the cost
> > > will become high enough that you will decide to migrate - because the
> cost
> > > of migration will be lower. That's a very natural economic scheme
> which is
> > > - I think - fair for maintainers, good for the product, and also
> eventually
> > > good for users (because they will get latest security fixes for
> example -
> > > even if this was not their goal).
> > >
> > > Regularly bumping the minimum version directly addresses goals 2, 3,
> and 4.
> > >
> > > It also achieves predictability, which I think is also important.
> > >
> > > The current policy also gives users a very clear and straightforward
> > > signal: "If you are at version X, your providers will stop getting new
> > > features and fixes." Done. Easy. Few exceptions exist where the steward
> > > explicitly committed to a longer timeline; we can state this clearly
> and
> > > ask the stewards for their predictable schedules.  And users have time
> to
> > > prepare for that. Especially that you know that "all" providers. New
> > > releases will stop on that date. And they cannot say "I did not know".
> I
> > > hope users with good planning and processes mark this date on their
> > > calendars and plan their budgets and teams accordingly.
> > >
> > > If every provider has a different minimum airflow version and support
> for
> > > older versions is dropped suddenly - this is bad. When you have no
> fixed,
> > > predictable timeline, you react instead of planning. And the reaction
> is
> > > often tactical rather than strategic.
> > >
> > > When I run Airflow 2.11 today, I know that no provider updates will be
> > > released after a given date. If I know months in advance, I can
> prepare. On
> > > the other hand, if I am using an HTTP provider today in 2.11 and your
> > > proposed scheme is implemented, the user has zero predictability
> regarding
> > > when new versions will stop being released. They might find a bug in a
> > > provider and hope for a fix, only to discover that for an unrelated
> reason,
> > > the next version of the provider is suddenly not released for their
> version
> > > of Airflow. The first thing that will happen is they will question the
> > > "breaking" decision and demand that we revert it. And they would be
> > > somewhat right - because they had no idea when it would happen, so they
> > > could not prepare.
> > >
> > > So .. in light of those scenarios above - what are the goals of
> changing it
> > > in the way you described? Is it just "keep our users from migrating to
> > > Airflow 3" or there are other goals? How do they compare to the 5 goals
> > > above ?
> > >
> > > J.
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Mar 8, 2026 at 9:49 AM Elad Kalif <el...@apache.org> wrote:
> > >
> > > > 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 <
> > > > dev@airflow.apache.org>
> > > > 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 <ka...@gmail.com>
> wrote:
> > > > >
> > > > > > I like your idea Jarek
> > > > > >
> > > > > > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com>
> 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 <
> > > > > > > dev@airflow.apache.org>
> > > > > > > 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 <
> eladkal@apache.org>
> > > > > 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 <
> > > > jscheffl@apache.org
> > > > > >
> > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Jarek Potiuk <ja...@potiuk.com>]

I'd also really like to see what others think here. I personally think
the current scheme is really good (in terms of process). Having
predictable dates and gently pushing people to upgrade is good. Having
stewards particularly interested in longer support with their
providers and committing to it is, I think a good and natural
extension of the new provider governance we introduced. And I believe
I've posted enough arguments, to show that a scheme where each
provider sets its own (unpredictable) time for dropping support is
quite problematic.

However, when it comes to the actual timing, we drop new provider
releases for 2.11. I would love to hear other voices on this topic.

I think what we are discussing here is not a "mature" product vision.
We have a mature product. That's undeniable. Whether it's 12 or 24
months makes little difference - just by providing compatibility,
testing it and releasing providers for older Airflow versions, we
already show that we actually care. Remember in Airflow 1, providers
were really part of Airflow, and you had to upgrade to the latest
Airflow to use any new provider features and bugfixes. Yes - you had
to upgrade to latest version of Airflow if you wanted to have this one
bugfix for http Operator or Hook. Even Airflow 1 was a really
"serious" product. So we are already **very** mature here. We not only
release those providers, but for about a year and a half now, we have
also run full compatibility tests with older Airflow versions. That's
already a lot to demand from essentially an open-source product.

I think what we are really talking about here is trading maintainer
effort against user effort to keep up with new changes. I am not sure
if "mature" platform means long support - and how long —especially
since we aren't dropping "support" but rather "maintenance." And
really it's about being able to use some new features we release in
the providers. As a community, we do not have "support", really. We
intend (though we don't commit—we bumped the minimum version for
several providers sooner than 12 months for various reasons) to
maintain things (mostly voluntarily) for a specific time.

So I would really love to hear - from the wider community. Is it a
major issue that the latest providers cannot be installed for Airflow
2? Is it really a major inconvenience for them to backport the most
important features, either individually or through service providers,
if they really want to do so? How does it compare to the increased
maintenance effort required for a longer duration by maintainers and
contributors who must deal with backward compatibility? (I helped
several contributors who were completely lost on how to run and fix
compatibility issues—the pain is real.)

J.

On Mon, Mar 9, 2026 at 7:04 PM Michał Modras via dev
<de...@airflow.apache.org> wrote:
>
> Personally, I'm fine with deprecations based on date or version. In this
> particular case, it is not really about Airflow 2.11, but rather Airflow 2
> as a whole major version. Which is still the most popular Airflow version
> adopted across the industry. Given all the changes Airflow 3 brings, 2.11
> deserves a longer compatibility period for providers than a random Airflow
> 2 minor version.
>
> In my view, the goal is clear - exactly as described, be gentle to the
> users, and do not push them too strongly to Airflow 3, regardless of how
> much we want everyone on the latest version. Across the industry,
> migrations take time. Sometimes a long time. We should build an image of
> Airflow as a mature platform, that does not drop support for hundreds or
> thousands of integrations across multiple providers in 12 months since a
> public launch of a major version - it is not a long time in the industry.
>
> On Sun, Mar 8, 2026 at 2:22 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > > I think we should consider changing the behavior by - upgrading the
> > minimum version when it causes issues, not by date.
> >
> > Question: What goal do you want to achieve this way? I think we should
> > generally optimize our processes based on the goal we want to achieve.
> >
> > I can see one goal it can achieve: Keeping our users from migrating to
> > Airflow 3. Which for me, personallly, is a "non-goal." But maybe there are
> > others I do not see..
> >
> > I think that would a) complicate things for us, b) prevent us from making
> > bold changes, heavy refactors and adding some "cross-cutting concerns"
> > across the providers, and c) lose the implicit property of our "provider
> > min-version support"—which incentivizes our users to migrate to newer
> > airflow versions. Yes, one of the reasons we have a minimum airflow version
> > policy is to gently encourage our users to migrate to a newer version of
> > Airflow. This was a deliberate goal when we introduced it. We wanted users
> > who need to use provider X's new feature to migrate to a newer version of
> > Airflow.  This remains a goal of this setup today.
> >
> > Removing min-airflow-version across the board benefits both maintainers and
> > the product. Namely, we can (and have in the past) make changes across all
> > providers, which generally simplified maintaining the code across them.  We
> > are now starting to implement some common patterns that we want to use
> > across all providers—AIP-99—which essentially elevates the importance of
> > Hooks and allows us to make essentially all of our integrations LLM-native.
> > And it's just the beginning. Most of such "across all provider" changes are
> > done by someone who does not know well those providers and this is already
> > big difficulty. If you add to the mix that for this provider, you would
> > have to make sure compatibility with 2.11+ and for that provider
> > compatibility with 3.2+ and for another provider for 3.1+, and you will
> > have to know all that and effectively learn some test patterns and
> > conditional cases for all providers adds quite an effort to any such
> > change.  If a steward commits to maintaining the old version, they will
> > bear the burden of implementing necessary changes to ensure
> > back-compatibility in their provider when we make such changes. They are
> > the experts, they know best how to address some problems - and author of a
> > "new cross cutting idea" will not have to worry about that (too much) - or
> > will get help from the steward.
> >
> > Also, maintaining compatibility is a burden today. Ask many of the
> > contributors (I helped many of them) who had to ensure their changes work
> > with compatibility tests - this is a significant burden. If you want to
> > ensure that changes in Provider A work with Airflow 2.11. 3.0. 3.1 - You
> > must run all tests with it, add conditional code, make some tests
> > conditional. Sometimes you need to copy&paste code from old versions, or
> > add new code to "common.compat". Those require extra effort. If we
> > maintainsupport for older versions for longer time, those problems will
> > only worsen—and quickly.
> >
> > These are the goals of the current implementation:
> >
> > 1) Address the need for some stewards to keep their integration available
> > in older versions
> > 2) Gently encourage users to migrate to the newer version of Airflow when
> > they need new features from providers
> > 3) Allow us to make bolder changes across many providers
> > 4) Limit the burden on maintainers to maintain compatibility.
> > 5) Predictability for the users
> >
> > Also note that 2) is very "soft." It blocks nothing; it deliberately moves
> > the burden from maintainers to users. Nothing prevents users of Airflow
> > 2.11 from keeping the latest version of the Http Provider that is
> > compatible with 2.11.  There is also nothing to prevent them from
> > backporting any of new changes that we implement to their Dags/Libraries if
> > they want to use it. This is open-source software, and the users can take
> > any new Http Hook implementation, adapt it to work on 2.11 and use it
> > internally in their Dags. The big difference is that the responsibility
> > lies with "them," not with maintainers. I think it's actually fair to
> > offload some of the difficulty with supporting old versions on the users.
> > Since migrating is their choice, we can expect them to make the necessary
> > effort if they want to use new features. I see no issue with it, I even see
> > it as a great incentive scheme - with the current setup:
> >
> > The longer a user delays migration the more costly it becomes if they want
> > to keep up with the provider's latest features. At some point, the cost
> > will become high enough that you will decide to migrate - because the cost
> > of migration will be lower. That's a very natural economic scheme which is
> > - I think - fair for maintainers, good for the product, and also eventually
> > good for users (because they will get latest security fixes for example -
> > even if this was not their goal).
> >
> > Regularly bumping the minimum version directly addresses goals 2, 3, and 4.
> >
> > It also achieves predictability, which I think is also important.
> >
> > The current policy also gives users a very clear and straightforward
> > signal: "If you are at version X, your providers will stop getting new
> > features and fixes." Done. Easy. Few exceptions exist where the steward
> > explicitly committed to a longer timeline; we can state this clearly and
> > ask the stewards for their predictable schedules.  And users have time to
> > prepare for that. Especially that you know that "all" providers. New
> > releases will stop on that date. And they cannot say "I did not know". I
> > hope users with good planning and processes mark this date on their
> > calendars and plan their budgets and teams accordingly.
> >
> > If every provider has a different minimum airflow version and support for
> > older versions is dropped suddenly - this is bad. When you have no fixed,
> > predictable timeline, you react instead of planning. And the reaction is
> > often tactical rather than strategic.
> >
> > When I run Airflow 2.11 today, I know that no provider updates will be
> > released after a given date. If I know months in advance, I can prepare. On
> > the other hand, if I am using an HTTP provider today in 2.11 and your
> > proposed scheme is implemented, the user has zero predictability regarding
> > when new versions will stop being released. They might find a bug in a
> > provider and hope for a fix, only to discover that for an unrelated reason,
> > the next version of the provider is suddenly not released for their version
> > of Airflow. The first thing that will happen is they will question the
> > "breaking" decision and demand that we revert it. And they would be
> > somewhat right - because they had no idea when it would happen, so they
> > could not prepare.
> >
> > So .. in light of those scenarios above - what are the goals of changing it
> > in the way you described? Is it just "keep our users from migrating to
> > Airflow 3" or there are other goals? How do they compare to the 5 goals
> > above ?
> >
> > J.
> >
> >
> >
> >
> >
> > On Sun, Mar 8, 2026 at 9:49 AM Elad Kalif <el...@apache.org> wrote:
> >
> > > 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 <
> > > dev@airflow.apache.org>
> > > 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 <ka...@gmail.com> wrote:
> > > >
> > > > > I like your idea Jarek
> > > > >
> > > > > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> > > > > > dev@airflow.apache.org>
> > > > > > 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 <el...@apache.org>
> > > > 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 <
> > > jscheffl@apache.org
> > > > >
> > > > > > > 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
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org

Re: [DISCUSS] Providers support for Airflow 2.11

[Michał Modras via dev <de...@airflow.apache.org>]

Personally, I'm fine with deprecations based on date or version. In this
particular case, it is not really about Airflow 2.11, but rather Airflow 2
as a whole major version. Which is still the most popular Airflow version
adopted across the industry. Given all the changes Airflow 3 brings, 2.11
deserves a longer compatibility period for providers than a random Airflow
2 minor version.

In my view, the goal is clear - exactly as described, be gentle to the
users, and do not push them too strongly to Airflow 3, regardless of how
much we want everyone on the latest version. Across the industry,
migrations take time. Sometimes a long time. We should build an image of
Airflow as a mature platform, that does not drop support for hundreds or
thousands of integrations across multiple providers in 12 months since a
public launch of a major version - it is not a long time in the industry.

On Sun, Mar 8, 2026 at 2:22 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> > I think we should consider changing the behavior by - upgrading the
> minimum version when it causes issues, not by date.
>
> Question: What goal do you want to achieve this way? I think we should
> generally optimize our processes based on the goal we want to achieve.
>
> I can see one goal it can achieve: Keeping our users from migrating to
> Airflow 3. Which for me, personallly, is a "non-goal." But maybe there are
> others I do not see..
>
> I think that would a) complicate things for us, b) prevent us from making
> bold changes, heavy refactors and adding some "cross-cutting concerns"
> across the providers, and c) lose the implicit property of our "provider
> min-version support"—which incentivizes our users to migrate to newer
> airflow versions. Yes, one of the reasons we have a minimum airflow version
> policy is to gently encourage our users to migrate to a newer version of
> Airflow. This was a deliberate goal when we introduced it. We wanted users
> who need to use provider X's new feature to migrate to a newer version of
> Airflow.  This remains a goal of this setup today.
>
> Removing min-airflow-version across the board benefits both maintainers and
> the product. Namely, we can (and have in the past) make changes across all
> providers, which generally simplified maintaining the code across them.  We
> are now starting to implement some common patterns that we want to use
> across all providers—AIP-99—which essentially elevates the importance of
> Hooks and allows us to make essentially all of our integrations LLM-native.
> And it's just the beginning. Most of such "across all provider" changes are
> done by someone who does not know well those providers and this is already
> big difficulty. If you add to the mix that for this provider, you would
> have to make sure compatibility with 2.11+ and for that provider
> compatibility with 3.2+ and for another provider for 3.1+, and you will
> have to know all that and effectively learn some test patterns and
> conditional cases for all providers adds quite an effort to any such
> change.  If a steward commits to maintaining the old version, they will
> bear the burden of implementing necessary changes to ensure
> back-compatibility in their provider when we make such changes. They are
> the experts, they know best how to address some problems - and author of a
> "new cross cutting idea" will not have to worry about that (too much) - or
> will get help from the steward.
>
> Also, maintaining compatibility is a burden today. Ask many of the
> contributors (I helped many of them) who had to ensure their changes work
> with compatibility tests - this is a significant burden. If you want to
> ensure that changes in Provider A work with Airflow 2.11. 3.0. 3.1 - You
> must run all tests with it, add conditional code, make some tests
> conditional. Sometimes you need to copy&paste code from old versions, or
> add new code to "common.compat". Those require extra effort. If we
> maintainsupport for older versions for longer time, those problems will
> only worsen—and quickly.
>
> These are the goals of the current implementation:
>
> 1) Address the need for some stewards to keep their integration available
> in older versions
> 2) Gently encourage users to migrate to the newer version of Airflow when
> they need new features from providers
> 3) Allow us to make bolder changes across many providers
> 4) Limit the burden on maintainers to maintain compatibility.
> 5) Predictability for the users
>
> Also note that 2) is very "soft." It blocks nothing; it deliberately moves
> the burden from maintainers to users. Nothing prevents users of Airflow
> 2.11 from keeping the latest version of the Http Provider that is
> compatible with 2.11.  There is also nothing to prevent them from
> backporting any of new changes that we implement to their Dags/Libraries if
> they want to use it. This is open-source software, and the users can take
> any new Http Hook implementation, adapt it to work on 2.11 and use it
> internally in their Dags. The big difference is that the responsibility
> lies with "them," not with maintainers. I think it's actually fair to
> offload some of the difficulty with supporting old versions on the users.
> Since migrating is their choice, we can expect them to make the necessary
> effort if they want to use new features. I see no issue with it, I even see
> it as a great incentive scheme - with the current setup:
>
> The longer a user delays migration the more costly it becomes if they want
> to keep up with the provider's latest features. At some point, the cost
> will become high enough that you will decide to migrate - because the cost
> of migration will be lower. That's a very natural economic scheme which is
> - I think - fair for maintainers, good for the product, and also eventually
> good for users (because they will get latest security fixes for example -
> even if this was not their goal).
>
> Regularly bumping the minimum version directly addresses goals 2, 3, and 4.
>
> It also achieves predictability, which I think is also important.
>
> The current policy also gives users a very clear and straightforward
> signal: "If you are at version X, your providers will stop getting new
> features and fixes." Done. Easy. Few exceptions exist where the steward
> explicitly committed to a longer timeline; we can state this clearly and
> ask the stewards for their predictable schedules.  And users have time to
> prepare for that. Especially that you know that "all" providers. New
> releases will stop on that date. And they cannot say "I did not know". I
> hope users with good planning and processes mark this date on their
> calendars and plan their budgets and teams accordingly.
>
> If every provider has a different minimum airflow version and support for
> older versions is dropped suddenly - this is bad. When you have no fixed,
> predictable timeline, you react instead of planning. And the reaction is
> often tactical rather than strategic.
>
> When I run Airflow 2.11 today, I know that no provider updates will be
> released after a given date. If I know months in advance, I can prepare. On
> the other hand, if I am using an HTTP provider today in 2.11 and your
> proposed scheme is implemented, the user has zero predictability regarding
> when new versions will stop being released. They might find a bug in a
> provider and hope for a fix, only to discover that for an unrelated reason,
> the next version of the provider is suddenly not released for their version
> of Airflow. The first thing that will happen is they will question the
> "breaking" decision and demand that we revert it. And they would be
> somewhat right - because they had no idea when it would happen, so they
> could not prepare.
>
> So .. in light of those scenarios above - what are the goals of changing it
> in the way you described? Is it just "keep our users from migrating to
> Airflow 3" or there are other goals? How do they compare to the 5 goals
> above ?
>
> J.
>
>
>
>
>
> On Sun, Mar 8, 2026 at 9:49 AM Elad Kalif <el...@apache.org> wrote:
>
> > 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 <
> > dev@airflow.apache.org>
> > 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 <ka...@gmail.com> wrote:
> > >
> > > > I like your idea Jarek
> > > >
> > > > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> > > > > dev@airflow.apache.org>
> > > > > 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 <el...@apache.org>
> > > 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 <
> > jscheffl@apache.org
> > > >
> > > > > > 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
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Jarek Potiuk <ja...@potiuk.com>]

> I think we should consider changing the behavior by - upgrading the
minimum version when it causes issues, not by date.

Question: What goal do you want to achieve this way? I think we should
generally optimize our processes based on the goal we want to achieve.

I can see one goal it can achieve: Keeping our users from migrating to
Airflow 3. Which for me, personallly, is a "non-goal." But maybe there are
others I do not see..

I think that would a) complicate things for us, b) prevent us from making
bold changes, heavy refactors and adding some "cross-cutting concerns"
across the providers, and c) lose the implicit property of our "provider
min-version support"—which incentivizes our users to migrate to newer
airflow versions. Yes, one of the reasons we have a minimum airflow version
policy is to gently encourage our users to migrate to a newer version of
Airflow. This was a deliberate goal when we introduced it. We wanted users
who need to use provider X's new feature to migrate to a newer version of
Airflow.  This remains a goal of this setup today.

Removing min-airflow-version across the board benefits both maintainers and
the product. Namely, we can (and have in the past) make changes across all
providers, which generally simplified maintaining the code across them.  We
are now starting to implement some common patterns that we want to use
across all providers—AIP-99—which essentially elevates the importance of
Hooks and allows us to make essentially all of our integrations LLM-native.
And it's just the beginning. Most of such "across all provider" changes are
done by someone who does not know well those providers and this is already
big difficulty. If you add to the mix that for this provider, you would
have to make sure compatibility with 2.11+ and for that provider
compatibility with 3.2+ and for another provider for 3.1+, and you will
have to know all that and effectively learn some test patterns and
conditional cases for all providers adds quite an effort to any such
change.  If a steward commits to maintaining the old version, they will
bear the burden of implementing necessary changes to ensure
back-compatibility in their provider when we make such changes. They are
the experts, they know best how to address some problems - and author of a
"new cross cutting idea" will not have to worry about that (too much) - or
will get help from the steward.

Also, maintaining compatibility is a burden today. Ask many of the
contributors (I helped many of them) who had to ensure their changes work
with compatibility tests - this is a significant burden. If you want to
ensure that changes in Provider A work with Airflow 2.11. 3.0. 3.1 - You
must run all tests with it, add conditional code, make some tests
conditional. Sometimes you need to copy&paste code from old versions, or
add new code to "common.compat". Those require extra effort. If we
maintainsupport for older versions for longer time, those problems will
only worsen—and quickly.

These are the goals of the current implementation:

1) Address the need for some stewards to keep their integration available
in older versions
2) Gently encourage users to migrate to the newer version of Airflow when
they need new features from providers
3) Allow us to make bolder changes across many providers
4) Limit the burden on maintainers to maintain compatibility.
5) Predictability for the users

Also note that 2) is very "soft." It blocks nothing; it deliberately moves
the burden from maintainers to users. Nothing prevents users of Airflow
2.11 from keeping the latest version of the Http Provider that is
compatible with 2.11.  There is also nothing to prevent them from
backporting any of new changes that we implement to their Dags/Libraries if
they want to use it. This is open-source software, and the users can take
any new Http Hook implementation, adapt it to work on 2.11 and use it
internally in their Dags. The big difference is that the responsibility
lies with "them," not with maintainers. I think it's actually fair to
offload some of the difficulty with supporting old versions on the users.
Since migrating is their choice, we can expect them to make the necessary
effort if they want to use new features. I see no issue with it, I even see
it as a great incentive scheme - with the current setup:

The longer a user delays migration the more costly it becomes if they want
to keep up with the provider's latest features. At some point, the cost
will become high enough that you will decide to migrate - because the cost
of migration will be lower. That's a very natural economic scheme which is
- I think - fair for maintainers, good for the product, and also eventually
good for users (because they will get latest security fixes for example -
even if this was not their goal).

Regularly bumping the minimum version directly addresses goals 2, 3, and 4.

It also achieves predictability, which I think is also important.

The current policy also gives users a very clear and straightforward
signal: "If you are at version X, your providers will stop getting new
features and fixes." Done. Easy. Few exceptions exist where the steward
explicitly committed to a longer timeline; we can state this clearly and
ask the stewards for their predictable schedules.  And users have time to
prepare for that. Especially that you know that "all" providers. New
releases will stop on that date. And they cannot say "I did not know". I
hope users with good planning and processes mark this date on their
calendars and plan their budgets and teams accordingly.

If every provider has a different minimum airflow version and support for
older versions is dropped suddenly - this is bad. When you have no fixed,
predictable timeline, you react instead of planning. And the reaction is
often tactical rather than strategic.

When I run Airflow 2.11 today, I know that no provider updates will be
released after a given date. If I know months in advance, I can prepare. On
the other hand, if I am using an HTTP provider today in 2.11 and your
proposed scheme is implemented, the user has zero predictability regarding
when new versions will stop being released. They might find a bug in a
provider and hope for a fix, only to discover that for an unrelated reason,
the next version of the provider is suddenly not released for their version
of Airflow. The first thing that will happen is they will question the
"breaking" decision and demand that we revert it. And they would be
somewhat right - because they had no idea when it would happen, so they
could not prepare.

So .. in light of those scenarios above - what are the goals of changing it
in the way you described? Is it just "keep our users from migrating to
Airflow 3" or there are other goals? How do they compare to the 5 goals
above ?

J.





On Sun, Mar 8, 2026 at 9:49 AM Elad Kalif <el...@apache.org> wrote:

> 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 <
> dev@airflow.apache.org>
> 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 <ka...@gmail.com> wrote:
> >
> > > I like your idea Jarek
> > >
> > > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> > > > dev@airflow.apache.org>
> > > > 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 <el...@apache.org>
> > 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 <
> jscheffl@apache.org
> > >
> > > > > 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
> > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Elad Kalif <el...@apache.org>]

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 <de...@airflow.apache.org>
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 <ka...@gmail.com> wrote:
>
> > I like your idea Jarek
> >
> > On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> > > dev@airflow.apache.org>
> > > 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 <el...@apache.org>
> 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 <jscheffl@apache.org
> >
> > > > 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
> > > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Vikram Koka via dev <de...@airflow.apache.org>]

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 <ka...@gmail.com> wrote:

> I like your idea Jarek
>
> On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> > dev@airflow.apache.org>
> > 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 <el...@apache.org> 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 <js...@apache.org>
> > > 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
> > > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Kaxil Naik <ka...@gmail.com>]

I like your idea Jarek

On Fri, 6 Mar 2026 at 21:25, Jarek Potiuk <ja...@potiuk.com> 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 <
> dev@airflow.apache.org>
> 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 <el...@apache.org> 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 <js...@apache.org>
> > 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
> > > > >
> > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Jarek Potiuk <ja...@potiuk.com>]

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 <de...@airflow.apache.org>
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 <el...@apache.org> 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 <js...@apache.org>
> 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
> > > >
> >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Michał Modras via dev <de...@airflow.apache.org>]

+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 <el...@apache.org> 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 <js...@apache.org> 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
> > >
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Elad Kalif <el...@apache.org>]

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 <js...@apache.org> 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
> >

Re: [DISCUSS] Providers support for Airflow 2.11

[Jens Scheffler <js...@apache.org>]

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
>

Re: [DISCUSS] Providers support for Airflow 2.11

[Michał Modras via dev <de...@airflow.apache.org>]

+1 on extending the providers support. Personally, I'd say May 2027 :) On
the Google provider, we'll be happy to do the work to keep it compatible
with AF2.11 & AF3.x. Migration between Airflow major versions is much
bigger undertaking than just upgrading to the next minor or patch version.
Many customers, including big organizations, take a long time to execute
the migration across their, sometimes numerous, Airflow deployments.

On Fri, Mar 6, 2026 at 2:18 PM Elad Kalif <el...@apache.org> 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
>