JeffryMAC commented on pull request #10013: URL: https://github.com/apache/airflow/pull/10013#issuecomment-699662421
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. 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. ---------------------------------------------------------------- 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]
