blag commented on issue #22356: URL: https://github.com/apache/airflow/issues/22356#issuecomment-1223412231
For Airflow core, it makes sense to me to have two different types of deprecation warnings: 1. A deprecation warning that is visible to Airflow users, eg: DAG authors by default. 2. Some sort of pending deprecation warning that is not made visible to Airflow users by default. Option 1 would be for things where deprecation is imminent. Example: A function is being deprecated during Airflow 2.4 development and release and is being removed during 2.6 development. So end users will be notified of its deprecation status during the 2.4 release, and through the 2.5 release, and it will be removed in the 2.6 release. Option 2 would be for things where deprecation is oncoming but not imminent (eg: "walk, but no need to run"). This could be used for things that will be deprecated in the next major (X) release, but not the next minor release (X.Y). Example: We're deprecating multiple arguments to `DAG()`, like `timetable=` and `schedule_interval=` and consolidating on a single one `schedule=`. But we will be supporting all three arguments through all 2.x releases, and only removing `timetable` and `schedule_interval` in 3.0. So we use `Airflow30PendingDeprecationWarning` (or something like that) until the last 1-2 2.x releases of Airflow, and for those last one to two 2.x releases, we switch those warnings over to using `Airflow30DeprecationWarning`. This allows us to gently (or "as gently as possible") move users over to only using `schedule` in the lead up to 3.0, _without_ immediately and loudly causing deprecation warnings to be issued for all existing deployed DAGs in Airflow 2.4, 2.5, etc. -- 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]
