> I expect the compatibility layer to be delivered when 3.0 is generally available for testing, and to continue to work during the entire duration of Airflow 3.x—this should not be a big ask since the 2.x line is not going to receive new features, and the new syntax should not break compatibility for until the theoretical 4.0.
I read the above statement as "yes we are adding the "Airflow 2 operators and DAGs working with Airflow 3" compatibility layer as part of the AIP. On Wed, Aug 7, 2024 at 10:32 AM Tzu-ping Chung <t...@astronomer.io.invalid> wrote: > I think I’m fine with having this as a provider that if someone wants to > maintain it. Not every provider needs to be maintained by every Airflow > maintainer anyway. I’m not making it a goal for the AIP, but there’s also > nothing in there that would prevent it from happening. While I don’t see > myself maintaining the provider, I’ll be happy to tweak things if it makes > the implementation easier too. > Now - this one seems to contradict it: "I’m not making it a goal for the AIP" - and "3rd party package" is especially concerning. I understood it otherwise - also after reading the updated AIP - and the "compatibility included" is what gets my +1). Also as far as I can see all the (+1s) above as I read them were also including the compatibility layer to be part of the AIP. And the updated AIP text explains it as well as part of the AIP. If we (as the community that is voting on it) - won't commit to supporting compatibility layer, then this is a huge risk for the adoption of Airflow 3 - huge risk, for very little benefits if you ask me. If we don't support the compatibility layer as a community and won't commit to supporting it, this is really the only change that expects the users to make bulk changes to most of their DAGs **before** the migration if they followed the "intentional" and correct way of authoring DAGs (and not misusing them). IMHO - supporting compatibility is a condition of the AIP and goal, rather than an option. The compatibility layer there should be tested and supported for us for as long we tell our users we support it. And we should be explicit about it. J.
