AlejandroMorgante commented on PR #69930: URL: https://github.com/apache/airflow/pull/69930#issuecomment-4986261008
Thanks, I agree that the main concern here is providing users with a **clear and predictable deprecation process**, especially given how widely Glue is used. To clarify the scope of this PR: **it does not remove `GlueCrawlerOperator` or change its existing behavior or signature**. The operator continues to create a missing crawler, update an existing crawler, and start it exactly as it does today. This PR only starts the deprecation period by emitting an `AirflowProviderDeprecationWarning` and directing users to the operation-specific alternatives. ## Amazon provider precedents I checked previous operator deprecations in the Amazon provider: - `RedshiftSQLOperator` was deprecated in Amazon provider 6.1.0 as part of [#25717](https://github.com/apache/airflow/pull/25717) and was removed in 8.0.0 by [#30755](https://github.com/apache/airflow/pull/30755). - `AwsLambdaInvokeFunctionOperator` was deprecated in Amazon provider 7.3.0 by [#29749](https://github.com/apache/airflow/pull/29749) and was also removed in 8.0.0 by [#30755](https://github.com/apache/airflow/pull/30755). In both cases, the existing operator remained functional during the deprecation period, users received a warning pointing to its replacement, and the actual removal happened separately in a major provider release with an explicit breaking-change notice. I propose following the same process for `GlueCrawlerOperator`: 1. Keep `GlueCrawlerOperator` fully functional and backward compatible. **(Done in this PR)** 2. Emit an `AirflowProviderDeprecationWarning` pointing users to the operation-specific operators. **(Done in this PR)** 3. Document the legacy operator and provide a clear migration path. **(Done in this PR)** 4. Keep it available for several provider releases so users have ample time to migrate. **(Planned deprecation policy)** 5. Consider any eventual removal only in a separate PR and a future major provider release, after maintainer consensus and with an explicit breaking-change notice. **(Future safeguard)** Therefore, users would **not be required to migrate immediately**, and deprecation would not imply an automatic or imminent removal. Any future removal would be a separate decision, with another review and a clearly communicated migration window. Would this provide the certainty and visibility you had in mind for the deprecation process? @vincbeck , @o-nikolas, what do you think about moving forward with this approach? If you are comfortable with it, we can proceed with the technical review to make sure everything else in the PR is in good shape. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
