Re: [DISCUSS] Sensor Improvements With Tirggers

Hi Jarek, Thanks for the questions :) , I completely agree with you , from 2.10 we have the start_from_trigger parameter, which , when set , allows a task to be executed directly from the triggerrer without worker involvement. I believe that for any sensor to be executed in the triggerer, a corre

[DISCUSS] Airflow 2/3 providers versioning support

Hello everyone, I have two important topics to discuss regarding Provider <> Airflow version support rules. *1) What is the "min Airflow version" support while we are transitioning to Airflow 3? * So far we had the [1] rule: > The default support timespan for the minimum version of Airflow (the

Re: [DISCUSS] Airflow 2/3 providers versioning support

Sorry I’m a bit lost in the long text. Is my understanding of the 2 questions correct? We currently guarantee that the minimum Airflow version supported by a provider is the release date of the next minor version, plus 12 months. You’re asking if this should be adjusted for Airflow 3, correct?

Re: [DISCUSS] Airflow 2/3 providers versioning support

> We currently guarantee that the minimum Airflow version supported by a provider is the release date of the next minor version, plus 12 months. You’re asking if this should be adjusted for Airflow 3, correct? Yes > Are you asking for guarantees the other way around, so Airflow version -> guarant

Re: [DISCUSS] Sensor Improvements With Tirggers

Thank you for bringing this up! I have added some comments to the document. I'm unsure if we really want or need to implement more complex logic for this. What I have in mind is simply adding helper functions to InternalSensorTrigger and continuing to use the run method in BaseTrigger. The main

[DISCUSS] New provider Common.time

Hi, I would like to propose a new provider. *Background* As noted in the comment on this PR , several operators and sensors related to time are currently located in the core of Airflow: BranchDayOfWeekOperator, BranchDateTimeOperator, DateTimeSensor,

Re: [DISCUSS] New provider Common.time

I like the idea, and you beat me to proposing this since in my prototyping of AIP-72 I realised it would be much much better if 100% of operators et al were providers. One thing in this case though: we shouldn't have `common` in the name as that should be a convention of saying "this provider i

Re: [DISCUSS] New provider Common.time

Thanks for owning it Rom! +1 from me The common is needed because we have convention where the providers are packed under entity https://github.com/apache/airflow/tree/main/airflow/providers Common isnt new. We already have common.compat, common.io, common.sql Personally I don't mind about the n

Re: [DISCUSS] New provider Common.time

I like that idea too! +1. The name does not bother me either, "common" can refer to "common use cases" or "common usage" which makes sense (at least to me). On 2024/08/14 13:23:26 Elad Kalif wrote: > Thanks for owning it Rom! > +1 from me > > The common is needed because we have convention wher

Re: [DISCUSS] New provider Common.time

+1 - and following the above comments - I also think it might make sense to bring all operators/triggers/sensors from airlfow package to a single provider package (rather than having separate "time", "python", "branch" (or whatever we choose for all the other operators). This is mainly because th

Re: [DISCUSS] New provider Common.time

> On 14 Aug 2024, at 15:11, Vincent Beck wrote: > > "common" can refer to "common use cases" or "common usage" which makes sense > (at least to me). It can mean multiple things, but I’d like it if we used it to mean one thing in Airflow :)

Re: [DISCUSS] New provider Common.time

I like it. - ferruzzi From: Ash Berlin-Taylor Sent: Wednesday, August 14, 2024 7:50 AM To: dev@airflow.apache.org Subject: RE: [EXT] [DISCUSS] New provider Common.time CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [VOTE] Release Airflow 2.10.0 from 2.10.0rc1

Hi, I did extensive tests of the release and besides a small bug in UI (which I rate non-blocking) did not find any problem. Smooth transition. +1 from my side. I am not familar with signature erc checks therefore I‘d call it non-bindung. If binding is needed I need to find time to do the othe

Re: [DISCUSS] New provider Common.time

> It can mean multiple things, but I’d like it if we used it to mean one thing in Airflow :) It does not have to be common. But Ash, if you have a proposal there that does not conflict with any other meaning used in Airflow already - don't be shy and constructively propose it :) On Wed, Aug 14, 2

Re: [DISCUSS] New provider Common.time

+1 for moving all the core operators, sensors, and triggers to new/existing providers. > New provider Common.time I agree with others who comment on the name. IMHO common providers should have abstract (or generic) providers/sensors/triggers used by at least two other providers, which is not the

Re: [DISCUSS] Sensor Improvements With Tirggers

Hi Wei Lee, Thanks for the review, While I was working on the POC , I had a bit of confusion about how to use the logic present inside the sensor execute method. for both with and without triggerer flow. so to make it work for both flows, I have moved out to execute logic with two methods. I appr

Re: [DISCUSS] Approaches to bugfixes for 2.10 after main becomes 3.0

Late to the discussion here but I agree that we should document the process (if we haven't already). I also think that the automatic cherry picker is worth exploring. I also came across one of the github action plugins for backporting and it looks pretty good: https://github.com/marketplace/action

Re: [RESULT][VOTE] July 2024 PR of the Month

Congratulations Niko! Thanks & Regards, Amogh Desai On Sat, Aug 3, 2024 at 12:01 AM Bishundeo, Rajeshwar wrote: > Awesome job Niko!! > > -- Rajesh > > > > > > > On 2024-08-02, 1:51 PM, "Buğra Öztürk" ozturkbugr...@gmail.com>> wrote: > > > CAUTION: This email originated from outside of the org

Re: Airflow 3 AIP Gold Rush! -- Great job everyone

Great job! Seeing a flood of emails (after coming back to the dev mail post a vacation) was scary at first, but it's awesome to see the kind of effort that was put in by everyone. Kudos to everyone! Glad to be part of such a happening community Thanks & Regards, Amogh Desai On Mon, Aug 5, 2024