Just one comment. It might be nit-picking and a question of wording. I
don't think we can say that `we guarantee` something. The whole ASF
licence is very explicit that we don't guarantee basically anything
and users are solely responsible for assessing their risks and we take
no responsibility
To Jarek's phrasing - I think it is mostly right. The way I think about it:
when deprecating we guarantee that for 6 months we will not do breaking
changes, but after that period, on an occasion of releasing a major
provider package version (which is probably breaking anyway) we can do
cleanup and
Hey Elad. I think (and let me repeat that) - nobody suggests that we
ALWAYS remove some deprecations after 6 months. The idea - as I see
it - is completely reversed. As I understand current idea is that we
say "By default we do not introduce any breaking changes (i.e. we do
not remove
Eugen, about your two items:
- What should be used instead
- The date after which the method/parameter/operator will be removed
The first is already included today in all deprecation warnings.
The second is a big -1 from me. We normally say that it will be removed in
the next major release.
Hi.
Thanks for feedback and discussion.
Let me summarise what actually I want to propose (because there were a lot
in my initial email).
My proposal is, in case of deprecation, to emit messages in the specific
format, example of the message:
“””
The “given” parameter is deprecated and will be
First, I'd like to say that I support Eugen's proposal and I agree with the
enhancements suggested by Jarek.
I'm a bit confused about Elad's point 3 - are you suggesting having a
global policy for all providers, or that we should not codify our approach
at all since different providers have
One more thing. This one is essentially impossible (Hyrum's law explains
that very well https://www.hyrumslaw.com/:
> The change is considered to be a breaking (in the context of google
providers package) if a DAG that was working before, stops to work after
the change.
I propose to change it
BTW. Another example of an exception would be a security fix. We **migh**
find a security issue that will require a breaking change. But then again -
the breaking change might **only** cover that security fix - we do not have
to remove all the deprecations in this case (but we could if we decide
I think it's a good idea to codify the rules, indeed what Elad mentioned,
we **mostly** follow a very similar approach, but it's not written
anywhere.
Re: points of Elad:
1. I am ok with 6 months, but I agree here we should not have "strict"
limits. It's fine to have some default (i.e.
This is not too much different than what we already do.
We deprecate then we remove. We almost never create breaking change without
deprecating first.
I'd like to raise a few notes:
1. Major releases can happen frequently. I see no problem with it. This is
more a question of what are the
Hi.
I would like to discuss/propose a deprecation policy for
apache-airflow-providers-google package, mostly for deprecating Airflow
operators (but not limited to it).
*Some background:*
Airflow google provider package (as most of other provider packages in
Airflow) has a tendency to constantly
11 matches
Mail list logo
