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.
We should be able to stop adding new features quite quickly after 3.0, or even immediately, so the package would be in bug-fixing mode. We should choose a cutoff time to stop fixing bugs at some point, but I don’t think we should make the decision now; it depends on how the package allows people to migrate—maintenance stops once it can successfully do so. One reason I’ve been calling this a “compat package” instead of `airflow.providers.compat` is maybe we’ll be able to have a more flexible timeline if it’s an entirely separate package instead of being bundled with other compat stuff needed for providers. I’m not sure if that’s needed—open for suggestions—but we can decide on that either way at any point before 3.0 is out. TP > On 28 Jul 2024, at 06:17, Vikram Koka <vik...@astronomer.io.INVALID> wrote: > > After I read about the migration issues, I was very concerned about this > AIP and was leaning against it. > I like where the discussion is heading now and generally feel more positive > at this point. > > I am still struggling however, to understand the timing of what would be > delivered when and in which release to enable compatibility. > And therefore, what the transition sequence and timeframe would be in > reality. > > > On Fri, Jul 26, 2024 at 12:03 PM Ferruzzi, Dennis > <ferru...@amazon.com.invalid> wrote: > >> I think I like where the discussion took this. I was +0 on it based on my >> initial reading and generally don't vote unless I feel more strongly than >> that, but based on the direction the conversation is going, I like the >> issues that have been addressed and adjustments that are being made. >> >> +1 (binding) >> >> >> - ferruzzi >> >> >> ________________________________ >> From: Jarek Potiuk <ja...@potiuk.com> >> Sent: Friday, July 26, 2024 9:48 AM >> To: dev@airflow.apache.org >> Subject: RE: [EXT] [VOTE] AIP-80: Explicit Template Fields in Operator >> Arguments >> >> 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. >> >> >> >> Yeah. I think if we have the operator compatibility and a way how we could >> just develop providers in "Airflow 3" mode that will keep automatically >> compatibility for Airlfow 2 (for a long-ish time) - I'd change my vote from >> +0.5 to +1. That would alleviate all my concerns. >> >> On Fri, Jul 26, 2024 at 5:49 PM Shahar Epstein <sha...@apache.org> wrote: >> >>> +1 (binding) - it's an important feature IMO, and after reading the AIP >> and >>> the comments here - I think that TP's suggestion for compatibility and >>> migration mitigates the related concerns. >>> >>> >>> On Thu, Jul 25, 2024 at 10:44 AM Tzu-ping Chung <t...@astronomer.io.invalid >>> >>> wrote: >>> >>>> Hi all, >>>> >>>> I’m calling for a vote on AIP-80: Explicit Template Fields in Operator >>>> Arguments. >>>> https://cwiki.apache.org/confluence/x/2grOEg >>>> >>>> This proposal aims to improve how Airflow defines template fields, and >>>> help users avoid annoying pitfalls currently exist. >>>> >>>> Discussion thread: >>>> https://lists.apache.org/thread/yjcgb6fhn365n3307blq4y4v50gjynsy >>>> >>>> Please vote accordingly: >>>> >>>> [ ] +1 approve >>>> [ ] +0 no opinion >>>> [ ] -1 disapprove with the reason >>>> >>>> Votes from PMC members and committers are binding, but everyone in the >>>> community is also encouraged to vote. >>>> >>>> The vote will run for 5 days and last until 2024-07-30 8:00 UTC. >>>> >>>> Consider this as my vote as +1. >>>> >>>> TP >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
