Thanks TP & everyone for the discussion here: +1 binding On Mon, 19 Aug 2024 at 13:07, Jarek Potiuk <ja...@potiuk.com> wrote:
> +1 (binding). Thanks for responding to the concerns of compatibility, I > think personally this is crucial to have good Airflow 3 adoption. > > On Mon, Aug 19, 2024 at 1:34 PM Tzu-ping Chung <t...@astronomer.io.invalid> > wrote: > > > Hi all, > > > > I have modified the AIP document to reflect the conclusions we had during > > the previous Dev call. Most significantly, the beginning of the Migration > > section has been rewritten to declare that Airflow 3 will continue to > > support the pre-AIP-80 templating syntax. > > > > Please take another look and tell me what you think. > > > > If nothing comes up, I will formally declare the AIP as accepted after > the > > next Dev call (22 Aug). Fortunately, we do have all the technically boxes > > ticked, so there’s no additional work needed if you feel the current > > version is good enough. > > > > TP > > > > > > > On 8 Aug 2024, at 17:50, Michał Modras <michalmod...@google.com > .INVALID> > > wrote: > > > > > > Yes, there are two options. One - forward compatibility layer, and two > - > > > backwards compatibility layer. > > > I strongly believe that if we care for Airflow 3 adoption, providing > > > forward compatibility layers only is not enough, and lack of backwards > > > compatibility layer in case of changes that bring mostly syntactic > value > > is > > > in my opinion against the principles we've discussed in the Airflow 3 > dev > > > calls (e.g. breaking backwards compatibility when there's value brought > > to > > > the users, assuring smooth migration, etc.) - here's where our views > > > differ. I think the discussion should be continued with more > stakeholders > > > in the Airflow 3 dev calls. > > > > > > On Thu, Aug 8, 2024 at 11:12 AM Tzu-ping Chung > <t...@astronomer.io.invalid > > > > > > wrote: > > > > > >> The topic here are TWO compatibility layers in this message: > > >> https://lists.apache.org/thread/4s58ho5cw1537sl9ql20n3xslxkjrhyy > > >> > > >> The first one is the path described in the AIP, which I consider the > > main > > >> way most people would migrate. > > >> > > >> The second one is what I consider would encourage users to not change > > >> things, and force maintainers to indefinitely maintain. I do not think > > this > > >> is worthwhile, and did not include it in the AIP. > > >> > > >> The community will provide a compatibility layer. The point of contest > > >> here is if we should support ANOTHER layer, either instead of or > > together > > >> with the one I proposed. > > >> > > >> > > >> > > >>> On 7 Aug 2024, at 21:11, Jarek Potiuk <ja...@potiuk.com> wrote: > > >>> > > >>>> 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. > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > >
