Looking at the PR I see you are talking specifically about removing
airflow/contrib/operators/ecs_operator.py.
I disagree with you that this doesn't count as a breaking change.
For example, if we remove that file:
I have a dag on Airflow 2.3. I upgrade to 2.4. My dag breaks.
That is 100% a breaking change to me.
-a
On Thu, Aug 4 2022 at 11:08:14 +01:00:00, Ash Berlin-Taylor
<a...@apache.org> wrote:
One question: Are you talking about removing things from
airflow.contrib, or things already with in airflow.providers.*?
-a
On Thu, Aug 4 2022 at 11:55:52 +02:00:00, Jarek Potiuk
<ja...@potiuk.com> wrote:
Hello everyone,
Following the discussion in
<https://github.com/apache/airflow/pull/25413> I have a proposal.
Why don't we remove all "contrib" and other Airflow 1.10 deprecated
classes to a separate package and add dependency to that package as
[contrib] or [deprecated] extra in Airflow - and release one of the
next 2.* (2.4/2.5) airflow versions without those classes ?
This should be possible I think (We could do it for all "contrib"
easily and for some other individual classes in "operators" and
"hooks" that would likely require a little dynamic python magic to
not override the folders).
There are a number of benefits:
0) lots of old, defunc mostly deprecation code can be removed from
the main repo - including lots of tests that verify that.
1) new users would not even know about those classes/contrib - less
confusion
2) many of those "contrib" classes are not backwards-compatible with
old 1.10 classes already as we had many "major" releases in many
providers - so this might be a little misleading for those who are
still in 1.10 that they can easily "migrate" without making any
changes
3) there are many users who even now use "contrib" and we could use
the opportunity to "guide them" into migration. To make it smoother,
we could likely implement dynamic attribute checking in packages and
raise appropriate instructions to those who still use it and migrate
to 2.5 or 2.6 (and they will still have the option to install the
"contrib" package). The instructions could be the same as in
deprecation messages today (but they would fail in case the
"contrib" package is not installed)
4) We give a great tool for admins of Airflow installation.
Currently the admins have no tools to force their users to
switch-off from using contrib if they still do. But with this one
they will simply be able to install airflow without the "contrib"
package and the users will have to adapt. We can even provide those
"Admins" instructions on how to build your own "contrib" package if
you want to do it gradually and ask your users to remove
class-by-class or whatever way you want.
Technically - we are not breaking SemVer compatibility - you can
still get back to the contrib if you install the separate package.
So we can do it without bumping Major version
WDYT?
J.
