You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by "Ferruzzi, Dennis" <fe...@amazon.com> on 2026/05/13 20:03:11 UTC
A new approach for version_compat.py?
RE: https://github.com/apache/airflow/blob/main/providers/common/compat/src/airflow/providers/common/compat/version_compat.py
Curious if there is a reason we went with the constants like this? There's likely a reason, but if not, we are now adding a constant for 3.3 and that will continue to grow. I'm wondering if there is a reason not to replace those constants with a helper like
def airflow_version_at_least(major: int, minor:int, patch:int = 0) -> bool:
return get_base_airflow_version_tuple() >= (major, minor, patch)
Then in code instead of importing the constant it would be `if airflow_version_at_least(3, 3):` which seems just as clear and easy.
- ferruzzi
Re: A new approach for version_compat.py?
Posted by Jarek Potiuk <ja...@potiuk.com>.
But... Removing it from all the operators and switching to common.compat is
probably worth it - we have almost the same version_compat.py repeated in
all providers, and I guess pretty much providers use common compat as
dependency (pretty much as I expected) so we could likely deduplicate a lot
of code that is now spread-out across repo, regardless if someone would
like to use helper or constant - that would be definitely worthy change :)
On Thu, May 14, 2026 at 6:23 PM Ferruzzi, Dennis <fe...@amazon.com>
wrote:
> Thanks for the context. I figured there was likely a reason.
> ________________________________
> From: Jarek Potiuk <ja...@potiuk.com>
> Sent: Wednesday, May 13, 2026 3:36 PM
> To: dev@airflow.apache.org <de...@airflow.apache.org>
> Subject: RE: [EXT] A new approach for version_compat.py?
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe.
> Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez
> pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que
> le contenu ne présente aucun risque.
>
>
>
> Hi Dennis,
>
> The constants do not grow infinitely; they roll. When we bump the
> min_version, we remove the lowest constants to force the removal of all
> obsolete compatibility code. This approach ensures no "harness" is left
> behind, preventing us from forgetting to delete code for unsupported
> versions.
>
> This standard was established after extensive discussion in December 2024 (
> https://lists.apache.org/thread/px36w3ph2mf0pmv377dtfc2nhpq8dqw1) and is
> documented here:
>
> https://github.com/apache/airflow/blob/main/contributing-docs/testing/unit_tests.rst#implementing-compatibility-for-provider-tests-for-older-airflow-versions
>
> The main drawback of using helpers is losing the compilation errors that
> mandate removing old compatibility logic when constants are deleted.
>
>
>
> Best,
> Jarek
>
> On Wed, May 13, 2026 at 10:03 PM Ferruzzi, Dennis <fe...@amazon.com>
> wrote:
>
> > RE:
> >
> https://github.com/apache/airflow/blob/main/providers/common/compat/src/airflow/providers/common/compat/version_compat.py
> >
> >
> > Curious if there is a reason we went with the constants like this?
> > There's likely a reason, but if not, we are now adding a constant for 3.3
> > and that will continue to grow. I'm wondering if there is a reason not
> to
> > replace those constants with a helper like
> >
> > def airflow_version_at_least(major: int, minor:int, patch:int = 0) ->
> > bool:
> > return get_base_airflow_version_tuple() >= (major, minor, patch)
> >
> >
> > Then in code instead of importing the constant it would be `if
> > airflow_version_at_least(3, 3):` which seems just as clear and easy.
> >
> > - ferruzzi
> >
>
Re: A new approach for version_compat.py?
Posted by "Ferruzzi, Dennis" <fe...@amazon.com>.
Thanks for the context. I figured there was likely a reason.
________________________________
From: Jarek Potiuk <ja...@potiuk.com>
Sent: Wednesday, May 13, 2026 3:36 PM
To: dev@airflow.apache.org <de...@airflow.apache.org>
Subject: RE: [EXT] A new approach for version_compat.py?
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque.
Hi Dennis,
The constants do not grow infinitely; they roll. When we bump the
min_version, we remove the lowest constants to force the removal of all
obsolete compatibility code. This approach ensures no "harness" is left
behind, preventing us from forgetting to delete code for unsupported
versions.
This standard was established after extensive discussion in December 2024 (
https://lists.apache.org/thread/px36w3ph2mf0pmv377dtfc2nhpq8dqw1) and is
documented here:
https://github.com/apache/airflow/blob/main/contributing-docs/testing/unit_tests.rst#implementing-compatibility-for-provider-tests-for-older-airflow-versions
The main drawback of using helpers is losing the compilation errors that
mandate removing old compatibility logic when constants are deleted.
Best,
Jarek
On Wed, May 13, 2026 at 10:03 PM Ferruzzi, Dennis <fe...@amazon.com>
wrote:
> RE:
> https://github.com/apache/airflow/blob/main/providers/common/compat/src/airflow/providers/common/compat/version_compat.py
>
>
> Curious if there is a reason we went with the constants like this?
> There's likely a reason, but if not, we are now adding a constant for 3.3
> and that will continue to grow. I'm wondering if there is a reason not to
> replace those constants with a helper like
>
> def airflow_version_at_least(major: int, minor:int, patch:int = 0) ->
> bool:
> return get_base_airflow_version_tuple() >= (major, minor, patch)
>
>
> Then in code instead of importing the constant it would be `if
> airflow_version_at_least(3, 3):` which seems just as clear and easy.
>
> - ferruzzi
>
Re: A new approach for version_compat.py?
Posted by Jarek Potiuk <ja...@potiuk.com>.
Hi Dennis,
The constants do not grow infinitely; they roll. When we bump the
min_version, we remove the lowest constants to force the removal of all
obsolete compatibility code. This approach ensures no "harness" is left
behind, preventing us from forgetting to delete code for unsupported
versions.
This standard was established after extensive discussion in December 2024 (
https://lists.apache.org/thread/px36w3ph2mf0pmv377dtfc2nhpq8dqw1) and is
documented here:
https://github.com/apache/airflow/blob/main/contributing-docs/testing/unit_tests.rst#implementing-compatibility-for-provider-tests-for-older-airflow-versions
The main drawback of using helpers is losing the compilation errors that
mandate removing old compatibility logic when constants are deleted.
Best,
Jarek
On Wed, May 13, 2026 at 10:03 PM Ferruzzi, Dennis <fe...@amazon.com>
wrote:
> RE:
> https://github.com/apache/airflow/blob/main/providers/common/compat/src/airflow/providers/common/compat/version_compat.py
>
>
> Curious if there is a reason we went with the constants like this?
> There's likely a reason, but if not, we are now adding a constant for 3.3
> and that will continue to grow. I'm wondering if there is a reason not to
> replace those constants with a helper like
>
> def airflow_version_at_least(major: int, minor:int, patch:int = 0) ->
> bool:
> return get_base_airflow_version_tuple() >= (major, minor, patch)
>
>
> Then in code instead of importing the constant it would be `if
> airflow_version_at_least(3, 3):` which seems just as clear and easy.
>
> - ferruzzi
>