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