Re: [VOTE] Airflow Providers prepared on March 04, 2024

+1 non binding Verified some dags, mostly around cncf providers. Looks good  On Wed, 6 Mar 2024 at 11:13 AM, Rahul Vats wrote: > +1 (non-binding). > > Verified running example DAG for below provides with no issues > > >- https://pypi.org/project/apache-airflow-providers-amazon/8.19.0rc1 >

Re: [VOTE] Airflow Providers prepared on March 04, 2024

+1 (non-binding). Verified running example DAG for below provides with no issues - https://pypi.org/project/apache-airflow-providers-amazon/8.19.0rc1 - https://pypi.org/project/apache-airflow-providers-apache-hive/7.0.1rc1 -

Re: [VOTE] Airflow Providers prepared on March 04, 2024

+1 (binding): tested /checked my changes. Checked reproducibility, licences, signatures, checksums - all looks good. On Tue, Mar 5, 2024 at 5:51 PM Vincent Beck wrote: > > +1 non binding. All AWS system tests are running successfully against > apache-airflow-providers-amazon==8.19.0rc1. You

Re: [DISCUSS] Deprecation policy for apache-airflow-providers-google package

Hey Elad. I think (and let me repeat that) - nobody suggests that we ALWAYS remove some deprecations after 6 months. The idea - as I see it - is completely reversed. As I understand current idea is that we say "By default we do not introduce any breaking changes (i.e. we do not remove

[DISCUSS] AIP-63, AIP-64, and AIP-65: DAG Versioning

Hello everyone! I'm excited to start a discussion around DAG Versioning in Airflow. It's been the most requested feature in the last 3 community surveys! AIP-63: DAG Versioning As this topic quickly becomes rather

[ANNOUNCE] CFP deadline for Airflow Summit 2024 is very close!

*Dear community,* We want to hear from you! Remember that the CFP for Airflow Summit 2024 is still open, please send your proposal and join us to celebrate a decade of Airflow in San Francisco! *Remember that *even though the CFP is open until April 17, we have an *early CFP deadline* for

Re: AIP-62 Getting Lineage from Hook Instrumentation

And of course I've forgot to attach link, here it is: https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-62+Getting+Lineage+from+Hook+Instrumentation wt., 5 mar 2024 o 20:01 Maciej Obuchowski napisał(a): > Hey, > I'd like to announce a new proposal. It proposes instrumenting Airflow >

AIP-62 Getting Lineage from Hook Instrumentation

Hey, I'd like to announce a new proposal. It proposes instrumenting Airflow Hooks and Object Storage to collect dataset updates automatically, to allow gathering lineage from PythonOperator and custom operators. Let me know what you think about this. The scope of this proposal was initially

[ANNOUNCE] Apache Airflow Helm Chart version 1.13.0 Released

Dear Airflow community, I am pleased to announce that we have released Apache Airflow Helm chart 1.13.0   The source release, as well as the "binary" Helm Chart release, are available:  Official Sources:

Re: [VOTE] Airflow Providers prepared on March 04, 2024

+1 non binding. All AWS system tests are running successfully against apache-airflow-providers-amazon==8.19.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/2852976ea6321b152ebc631d30d5526703bc6590_8.19.0rc1.html On 2024/03/04 21:34:04 Elad Kalif

[RESULT][VOTE] Release Apache Airflow Helm Chart 1.13.0 based on 1.13.0rc1

Hello all, The vote to release Apache Airflow Helm Chart version 1.13.0 based on 1.13.0rc1 is now closed. The vote PASSED with 3 binding "+1", 2 non-binding "+1" and 0 "-1" votes: "+1" Binding votes: - Jed Cunningham - Jarek Potiuk - Ephraim Anierobi "+1" Non-Binding votes: - Amogh

Re: [DISCUSS] Deprecation policy for apache-airflow-providers-google package

Eugen, about your two items: - What should be used instead - The date after which the method/parameter/operator will be removed The first is already included today in all deprecation warnings. The second is a big -1 from me. We normally say that it will be removed in the next major release.

Re: [DISCUSS] Deprecation policy for apache-airflow-providers-google package

Hi. Thanks for feedback and discussion. Let me summarise what actually I want to propose (because there were a lot in my initial email). My proposal is, in case of deprecation, to emit messages in the specific format, example of the message: “”” The “given” parameter is deprecated and will be