vincbeck commented on PR #51056:
URL: https://github.com/apache/airflow/pull/51056#issuecomment-2916580928
> I wanted to ask for some guidance regarding version compatibility:
>
> This feature depends on AssetWatcher, which were introduced in Airflow
3.0. Given that, what’s the recommended approach here?
>
> Should I add some kind of version check in the code?
>
> Or should I just document that this trigger is only compatible with
Airflow 3.0+?
>
> The reason I’m asking is that this dependency is currently causing
compatibility test failures in CI.
>
> How should I best handle this situation — should I aim for compatibility,
skip certain tests, or is it acceptable to limit this feature to Airflow 3.0+?
>
> Would appreciate any advice on how best to handle version compatibility
for providers when introducing features that rely on newer core components.
>
> Thanks!
Yes, you need to do 2 things:
- Raise an exception if the trigger is used in Airflow < 3
- Skip the tests if Airflow < 3
Basically, something like this.
In
`providers/postgres/src/airflow/providers/postgres/triggers/postgres_cdc.py`,
you need to do:
```
try:
from airflow.triggers.base import BaseEventTrigger, TriggerEvent
except ImportError as e:
raise AirflowOptionalProviderFeatureException("Event-driven scheduling
is only compatible with Airflow versions >= 3.0.0")
```
In `providers/postgres/tests/unit/postgres/triggers/test_postgres_cdc.py`,
you need to do:
```
if not AIRFLOW_V_3_0_PLUS:
pytest.skip("Event-driven scheduling is only compatible with Airflow
versions >= 3.0.0", allow_module_level=True)
```
--
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]
