And there is a possibility of having a switch to turn those deprecation warnings into errors in this case - still giving the admin of Airflow installation (even selectively) to migrate out of contrib for their users.
On Thu, Aug 4, 2022 at 3:52 PM Jarek Potiuk <[email protected]> wrote: > > This is the issue though. apache-airflow does not depend on > apache-airflow-providers-google >= 8.0, so you can still be on the same > version of the provider on 2.3 and 2.4, but by _only_ upgrading > apache-airflow package your DAG now breaks. > > Correct. The difference is that by only upgrading apache-airflow alone you > will break it. And I see why this might be seen as "problematic". > > But I have another idea. Why - rather than keeping the deprecations in the > code we load such deprecated we add dynamic attributes to __init__ of > airflow.contrib, airflow.operators, airflow.hooks. (to resolve to provider > operators). > > Such dynamic attributes will be invisible to autocompletion, will not be > documented with APIs nor visible in the source code (Except deep inspection > of __init__ in those packages). > > This has no compatibility breaking potential whatsoever > > > J. > > > On Thu, Aug 4, 2022 at 3:47 PM Ash Berlin-Taylor <[email protected]> wrote: > >> On Thu, Aug 4 2022 at 13:59:23 +02:00:00, Jarek Potiuk <[email protected]> >> wrote: >> >> When you migrate to Airflow 2.4 and it links to the 8.0 version of Google >> provider (assume 2.3 linked to 7) you have to make changes to make it work >> in backwards incompatible way - you have to downgrade google provider to >> 7.0. You still can do it, but it is not "out-of-the-box". >> >> >> This is the issue though. apache-airflow does not depend on >> apache-airflow-providers-google >= 8.0, so you can still be on the same >> version of the provider on 2.3 and 2.4, but by _only_ upgrading >> apache-airflow package your DAG now breaks. >> >> >>
