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