mik-laj edited a comment on pull request #10013: URL: https://github.com/apache/airflow/pull/10013#issuecomment-699664402
@potiuk I created a ticket: https://github.com/apache/airflow/issues/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. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
