Yeah, that sounds like it could work.
On Thu, Aug 4 2022 at 15:52:28 +02:00:00, Jarek Potiuk
<ja...@potiuk.com> 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 <a...@apache.org
<mailto:a...@apache.org>> wrote:
On Thu, Aug 4 2022 at 13:59:23 +02:00:00, Jarek Potiuk
<ja...@potiuk.com <mailto:ja...@potiuk.com>> 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.
