Re: [DISCUSS] Minimum versions of providers for Airflow 3

A draft PR here (i will split it as there are few unrelated changes) https://github.com/apache/airflow/pull/49103 -> but it shows how we can automatically set the min versions in "apache-airflow" meta-package (with 6-months-old provider versions). That will quite likely help to get the "Resolution

Re: [DISCUSS] Minimum versions of providers for Airflow 3

Oh hang on wait a moment. Is aiobotocore a new extra that is not available in 2.10.5 or any early versions? If that is the case then I’d instead vote that we don’t add new extras to `apache-airflow`, and we instead remove it. I grudgingly accept that having `apache-airflow[amazon]` make sense,

Re: [DISCUSS] Minimum versions of providers for Airflow 3

Just checked, no this was in 2.10 releases. NM then. Still, I think we should not add new extras to `apache-airflow` in general, and definitely not for anything other than direct provider “short-names”. -ash > On 11 Apr 2025, at 09:02, Ash Berlin-Taylor wrote: > > Oh hang on wait a moment. >

[DISCUSSION] Proposal to Add Couchbase Provider to Apache Airflow

Couchbase has customers already using Apache Airflow, and having an officially supported provider within the ecosystem would simplify integration, improve reliability, and encourage adoption. We previously released airflow-providers-couchbase

Re: [DISCUSSION] Proposal to Add Couchbase Provider to Apache Airflow

I am not convinced. First of all what do you mean by visibility ? I see no problem with the visibility of your current provider - couchbase seems to have well established ecosystem with multiple plugins and extensions - https://github.com/Couchbase-Ecosystem and I would say it's quite likely Couch

Re: [DISCUSS] Minimum versions of providers for Airflow 3

Agreed on not having extras apart from providers. On Fri, 11 Apr 2025 at 13:36, Ash Berlin-Taylor wrote: > Just checked, no this was in 2.10 releases. NM then. > > Still, I think we should not add new extras to `apache-airflow` in > general, and definitely not for anything other than direct prov

Re: [DISCUSS] Minimum versions of providers for Airflow 3

That's a bit of a different topic :) - I was only asking about the minimum provider versions. And I think no-one wants to add new extras - but we do have a bunch of them already. What we have now is that (see pyproject-toml files in both) : * `apache-airflow-core` has a few of those historicall

Re: [DISCUSS] Minimum versions of providers for Airflow 3

Sounds good On Fri, 11 Apr 2025 at 16:16, Jarek Potiuk wrote: > That's a bit of a different topic :) - I was only asking about the minimum > provider versions. > > And I think no-one wants to add new extras - but we do have a bunch of > them already. What we have now is that (see pyproject-tom

[ANNOUNCE] Airflow main is now targeting 3.1

Hey everyone, As we approach the final stages of the Airflow 3.0.0 release, the main branch is now officially targeting Airflow 3.1. *What this means*: • PR authors and contributors should continue working as usual -- nothing changes in how PRs are submitted or merged. • However, starting now, al

Re: [ANNOUNCE] Airflow main is now targeting 3.1

Just one comment - following our discussion.. I perfectly understand we want to take more control now on what is merged. And if you want to take responsibility there then I am fine ( but also do not envy you :) I think we just need to clarify who and when should add the backport-to labels PRS (i

Re: [VOTE] Airflow Providers prepared on April 10, 2025

+1 non binding for apache-airflow-providers-amazon==9.6.0rc1. All AWS system tests are passing against apache-airflow-providers-amazon==9.6.0rc1. You can see the results here: https://aws-mwaa.github.io/#/open-source/system-tests/version/6bd535471819074f74b0c3a3251a823be24c61b0_9.6.0rc1.html.

Re: [ANNOUNCE] Airflow main is now targeting 3.1

Yeah, I removed that label, too, to avoid any confusion. Once 3.0.0 is officially released, we’ll return to `backport-to-v3-0-test` for automatic backport -- where the PR author or a committer could do that -- but we can discuss than once we reach there. I think we just need to clarify who and wh

Re: [DISCUSSION] Proposal to Add Couchbase Provider to Apache Airflow

Shyam, First off, I'm really glad to hear that Couchbase is interested in a deeper integration with Airflow and that Couchbase users are already finding value in it. Just to follow up with a couple of specific questions around your request: Could you share more about what's missing today with the

Re: [VOTE] Airflow Providers prepared on April 10, 2025

+1 (binding) - Checked SVN, Check in Docker, Reproducible package build, Licenses, Signatures (All except edge) Note: I was surprised that I found edge provider in the delivered package though I assume (again, but no explicit list given) that edge is not voted on. Reproducibility check with edge

Re: [VOTE] Airflow Providers prepared on April 10, 2025

During release I manually mark edge as not ready so it won't create docs for it. The fact that we can't push it to PyPi doesnt mean we don't test it hence I pushed it to SVN. We vote only on the providers rc listed in this email בתאריך שבת, 12 באפר׳ 2025, 00:35, מאת Jens Scheffler ‏: > +1 (bindi