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