Hello everyone, We know from a previous survey that users tend to upgrade providers together with Airflow core. This is also consistent with what I hear from talking to users in the community. Upgrading the provider separately is done mostly when there is a need (relevant bug fix, needed feature, etc...) This is something that we should prepare for. While we treat providers as independent packages users may see this as part of Airflow core.
I can say for myself that one of the challenges of upgrading 1.10 -> 2 was provider packages. My suggestion is to take the risk / problem away. If we remove all deprecations users will have to handle them while they are on Airflow 2.x and before they are migrating to Airflow 3.x - To my perspective this will allow a smoother migration. The reason I suggest to do it before Airflow 2.11 is because we treat 2.11 as a bridge release thus I'd like the constraints for this release to have the provider versions after removal of deprecations. This is a process we already started with cncf.kubernetes and amazon providers that removed all their deprecations: https://github.com/apache/airflow/pull/43689 https://github.com/apache/airflow/pull/42450 *I'd like to focus the discussion around the following proposal:* We will remove all deprecations from providers prior to Airflow 2.11 (Providers that already did this recently don't have to do it again if we added new deprecations), Given the mixed governance model for providers ( https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model-for-3rd-party-related-community-providers ) Stackholders who maintain a specific provider can ask to be excluded. The exclusion will be registered and referenced in the guides/tools we will introduce for Airflow 3 migration. Regards, Elad
