+1 . Very good and well thought proposal coming from a lot of discussions we held on slack with a number of people.
Great for the users and also recognizing our stakeholders needs and their willingness to maintain their providers in the way it is best for their user base (both within their services and outside) While we know such an exclusion is now requested (and very consistent and good policy proposed) by Google (we should likely register the policy somewhere in Google provider's readme BTW) - similar ones.could be added by other stakeholders not only as big as Google, Amazon and Microsoft. But also smaller providers could benefit from it if they had any stake lholder who would like to define and follow through their deprecation policy - for example Teradata could do the same already but others are more than welcome to follow and both - set the rules and commit to maintaining them. This is a great opportunity for others to step and raise their hand and say 'hey I would like to take more responsibility for that provider and here are the rule I propose and commit to keep it maintained. BTW. I know Microsoft team (kudos to Ambika!) is working on system test dashboard (yay!!!) so finally we may get have all the stakeholders from the big clouds involved and active in our community, and also having Astronomer as leading 3.0 and of course biggest contributor, and all the individual contributors - that makes it a very nice, sustainable community around Airflow and makes me really bullish on the future of Airflow! It's a really great to see how we all collaborate respect and recognize each-others needs. J niedz., 17 lis 2024, 09:30 użytkownik Elad Kalif <elad...@apache.org> napisał: > 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 >
