Airflow 3: python operators deprecations removal
Airflow 3: python operators deprecations removal
We need to wait with breaking changes to core operators/sensors
See https://lists.apache.org/thread/2dmlqkcmyomm4q7rrovygs6bw655zx07
Are we planning to introduce new provider in Airflow 3?
We need to wait with breaking changes to core operators/sensors See https://lists.apache.org/thread/2dmlqkcmyomm4q7rrovygs6bw655zx07
Are we planning to introduce new provider in Airflow 3?
But... @eladkal we shoudl "clean-up" before carrying the legacy to new operators.. or? In my eyes we shoudl not carry-over deprecations.
Newsfragment is missing though :-D Please add...
Newsfragment is missing though :-D Please add...
Added the news fragment for this change.
~If we move the operator to providers there is no need for newsfragment. The breaking change will be in providers not in core.~
I see two other deprecations in python.py - can you also remove these in the scope of the PR?
Newsfragment is missing though :-D Please add...
I have added the news fragment.
I see two other deprecations in python.py - can you also remove these in the scope of the PR?
Serialization code refactoring changes added recently (may be 2.10). Does it make sense to remove them immediately?
I see two other deprecations in python.py - can you also remove these in the scope of the PR?
Serialization code refactoring changes added recently (may be 2.10). Does it make sense to remove them immediately?
Deprecated is deprecated I'd say. It is by warning announced to be gone. Even if it is just announced in 2.10, this means 6+ months of notice before release. As well if we not remove in 3.0, then we would need to carry until 4.0
I see two other deprecations in python.py - can you also remove these in the scope of the PR?
Serialization code refactoring changes added recently (may be 2.10). Does it make sense to remove them immediately?
Deprecated is deprecated I'd say. It is by warning announced to be gone. Even if it is just announced in 2.10, this means 6+ months of notice before release. As well if we not remove in 3.0, then we would need to carry until 4.0
Yes. However, I want to reconfirm once before making the changes. @eladkal / @potiuk WDYT?
I think we need to wait for next dev call where we discuss "standard" provider's scope
I think we need to wait for next dev call where we discuss "standard" provider's scope
Any update on this?
@potiuk / @eladkal are we good to merge this PR?
@potiuk / @eladkal are we good to merge this PR?
No - not really - there is another change in progress - https://github.com/apache/airflow/pull/42081 that moves Python operators to "standard" providers, and I think what you did here should be done as part of it, rather than separate PR from you - so I think the best course of action is to close that one and get you @dirrao to review and make comment in the #42081 so that we make sure deprecations are removed in the standard provider.
This should be generally done in the same way for all operators that are part of the "core" - we should move all of them to " "standard" and remove the deprecation "along the way".
cc: @gopidesupavan.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.