Change DeprecationWarning to AirflowDeprecationWarning

[eladkal]

Body

It's becoming hard to differentiate between all warnings raised in logs.
Airflow uses many packages that also raise warnings.

I suggest to create AirflowDeprecationWarning.
We can even have similar mechanism to sqlalchemy that has SADeprecationWarning and specifying the version this warning started from that way it will also be easier to keep track.
https://github.com/sqlalchemy/sqlalchemy/blob/769fa67d842035dd852ab8b6a26ea3f110a51131/lib/sqlalchemy/exc.py#L779

We can also have AirflowProviderDeprecationWarning to differentiate from Airflow core

Originally posted in #22333 (comment)

What do others think?

Committer

• I acknowledge that I am a maintainer/committer of the Apache Airflow project.

[ashb]

I agree think we should copy what other projects do (SQLA, Celery, Djanog etc), and have a RemovedInAirflow3 warning subclass.

[ashb]

Oh -- we can't (easily) use such a warning class in providers as they still need to work on Airflow 2.1 (at the moment anyway)

[eladkal]

in AirflowProviderDeprecationWarning i meant for warnings which are in scope of the provider itself and are not tied to Airflow core (like Operator rename).

[blag]

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.