@kaxil this needs to be released in 1.10.X release so that we can prepare for the upgrade to 2.0

@kaxil this needs to be released in 1.10.X release so that we can prepare for the upgrade to 2.0

@JeffryMAC why?

@turbaszek the update of import paths should take place on version 1.10. Otherwise it will not be possible to migrate gradually according to our plan. We first want to update all operators using backport packages on version 1.10, and then the update Airflow to 2.0

because this operator is in Airflow core so the release of providers isn't going to help here.
In fact this is very very confusing because the operator was released in providers https://pypi.org/project/apache-airflow-backport-providers-email/ before moved to core.

So people might thing they are ready to 2.0 while in fact they might not be.
I thought there will be a new release to https://pypi.org/project/apache-airflow-backport-providers-email/ specifying that the operator there is deprecated and should be used with different path.

@mik-laj Should we rethink whether the operator shoudl be moved back to the providers? I think it would not hurt if we keep two copies of the operator. I am also not very happy that this operator has been removed from the providers, it's breaking change and I thin the users like @JeffryMAC did not get any warning and get confused.

I am open-minded, but I would be careful about making two copies of the same operator. I think we can migrate e-mail operator in 1.10 and then make sure by upgrade-check that the user is using a new path adapted to Airflow 2.0. The new backport providers for email can direct the user to the core operator.

Yeah. I think backport package which will be directing to core (and have >= 1.10.13 dependency would be probably best.

Could you please revert that part of the changes? I can do the >= 1.10.13 dependency when I release the backport packages finally.

@potiuk There are more cases that require an update in 1.10. These operators also change their mdoule name (most often they will lose the suffix _operator) and will never be released. They have not been updated in Airflow 2.0 to facilitate the releasing of backport packages.

   1 airflow/operators/bash.py
   1 airflow/operators/branch_operator.py
   1 airflow/operators/dagrun_operator.py
   1 airflow/operators/dummy_operator.py
   1 airflow/operators/email.py
   1 airflow/operators/generic_transfer.py
   1 airflow/operators/latest_only_operator.py
   1 airflow/operators/python.py
   1 airflow/operators/sql.py
   1 airflow/operators/subdag_operator.py
   1 airflow/sensors/base_sensor_operator.py
   1 airflow/sensors/bash.py
   1 airflow/sensors/date_time_sensor.py
   1 airflow/sensors/external_task_sensor.py
   1 airflow/sensors/filesystem.py
   1 airflow/sensors/python.py
   1 airflow/sensors/smart_sensor_operator.py
   1 airflow/sensors/sql_sensor.py
   1 airflow/sensors/time_delta_sensor.py
   1 airflow/sensors/time_sensor.py
   1 airflow/sensors/weekday_sensor.py

What do you propose @mik-laj ?

I'm working on the ticket just now.

My point for raising this is that Airflow 2.0 is months aways and if PRs will be raised to fix/change/add new functionalities to this operator (or others like it) these changes are not reflected to the users. I think there is BIG assumption here that the changes are only import paths. That won't neccerly the case. It's one thing on migration to change paths it's a whole another thing to start testing so many functionality changes.

I share @mik-laj not to maintain two copies of the same code it will be even more confusing.
This is a temporary situation resulted by the extensive refactoring Airflow had/has.

My suggestion here is:

1. Readd the email provider (with no code) but only a deprecation warning that the operator is moved to core and indicate what Airflow version is needed.
2. Users who uses email provider will have failures if upgraded to the next release of providers but will always be able to pin to previous version.
3. Release all "new" core operator in the next 10.x release

Side Question: Why can't core be a provider Airflow? It will make things easier for the provider release but also in the long run it might be easier as users know that all hooks/operators/sensor are in provider lib and not "playing" around the project.

@potiuk I created a ticket: #11178

@JeffryMAC This is a big assumption, but it can happen with any update and it will be rather difficult for us to do something about it. Any change in behavior between releases is described in UPGRADING.md.

In the case of EmailOperator, no changes have been made to the operator, but it is possible that there are changes to the airlfow.utils that it uses.

Users who uses email provider will have failures if upgraded to the next release of providers but will always be able to pin to previous version.

Operator e-mail practically does not contain the code. All of this operator's logic is part of the Airflow core.

Side Question: Why can't core be a provider Airflow? It will make things easier for the provider release but also in the long run it might be easier as users know that all hooks/operators/sensor are in provider lib and not "playing" around the project.

The core operator uses a private API or requires changes in the Scheduler to make them work properly, eg SubDagOperator. Python / Bash Operator is also part of the core so that a clean Airflow install can run example DAGs and that users can test Airflow without installing additional packages.

@JeffryMAC Would you like readd email providers with a deprecation warning? This is probably the best solution right now. I am very happy to help with the review.