[VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Kaxil Naik 
Hey fellow Airflowers,

I am thrilled to announce the availability of Apache Airflow 3.0.0rc2 & *Task
SDK 1.0.0rc2* for testing!

This email is calling for a vote on the release,
which will last at least 7 days until 17th April.
and until 3 binding +1 votes have been received.

Consider this my (non-binding) +1.

Airflow 3.0.0rc2 is available at:
https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/

"apache-airflow" Meta package:


   - *apache-airflow-3.0.0-source.tar.gz* is a source release that comes
   with INSTALL instructions.
   - *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist" release.
   - *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
   wheel "binary" release.

"apache-airflow-core" package


   - *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
   release.
   - *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
   wheel "binary" release.

Task SDK 1.0.0rc2 is available at:
https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/

"apache-airflow-task-sdk" package

   - *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
   - *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python "sdist"
   release.
   - *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary Python
   wheel "binary" release.


Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but all members of the community
are encouraged to test the release and vote with "(non-binding)".

The test procedure for PMC members is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members

The test procedure for contributors and members of the community who would
like to test this RC is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors

Please note that the version number excludes the 'rcX' string, so it's now
simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will allow us
to rename the artifact without modifying
the artifact checksums when we actually release.

Release Notes:
https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst


*Testing Instructions using PyPI*:

You can build a virtualenv that installs this, and other required packages
(e.g. task sdk), like this:

```

uv venv

uv pip install apache-airflow --pre

```

Get Involved

We encourage the community to test this release and report any issues or
feedback. Your contributions help us ensure a stable and reliable Airflow
3.0.0 release. Please report issues using Github at
https://github.com/apache/airflow/issues and mark that this is an issue in
3.0.0. For an updated list of all known issues in the beta can also be
found in the above link with the label “affected_version:3.0.0rc”

A huge thank you to all the contributors who have worked on this milestone
release!
Best,
Kaxil

Re: [VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Kaxil Naik 
Like last time, docker images are still building! I will email here once
they are published.

On Thu, 10 Apr 2025 at 22:20, Kaxil Naik  wrote:

> Hey fellow Airflowers,
>
> I am thrilled to announce the availability of Apache Airflow 3.0.0rc2 & *Task
> SDK 1.0.0rc2* for testing!
>
> This email is calling for a vote on the release,
> which will last at least 7 days until 17th April.
> and until 3 binding +1 votes have been received.
>
> Consider this my (non-binding) +1.
>
> Airflow 3.0.0rc2 is available at:
> https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/
>
> "apache-airflow" Meta package:
>
>
>- *apache-airflow-3.0.0-source.tar.gz* is a source release that comes
>with INSTALL instructions.
>- *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist" release.
>- *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
>wheel "binary" release.
>
> "apache-airflow-core" package
>
>
>- *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
>release.
>- *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
>wheel "binary" release.
>
> Task SDK 1.0.0rc2 is available at:
> https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/
>
> "apache-airflow-task-sdk" package
>
>- *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
>- *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python "sdist"
>release.
>- *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary
>Python wheel "binary" release.
>
>
> Public keys are available at:
> https://dist.apache.org/repos/dist/release/airflow/KEYS
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
> Only votes from PMC members are binding, but all members of the community
> are encouraged to test the release and vote with "(non-binding)".
>
> The test procedure for PMC members is described in:
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
>
> The test procedure for contributors and members of the community who would
> like to test this RC is described in:
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
>
> Please note that the version number excludes the 'rcX' string, so it's now
> simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will allow
> us to rename the artifact without modifying
> the artifact checksums when we actually release.
>
> Release Notes:
> https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst
>
>
> *Testing Instructions using PyPI*:
>
> You can build a virtualenv that installs this, and other required packages
> (e.g. task sdk), like this:
>
> ```
>
> uv venv
>
> uv pip install apache-airflow --pre
>
> ```
>
> Get Involved
>
> We encourage the community to test this release and report any issues or
> feedback. Your contributions help us ensure a stable and reliable Airflow
> 3.0.0 release. Please report issues using Github at
> https://github.com/apache/airflow/issues and mark that this is an issue
> in 3.0.0. For an updated list of all known issues in the beta can also be
> found in the above link with the label “affected_version:3.0.0rc”
>
> A huge thank you to all the contributors who have worked on this milestone
> release!
> Best,
> Kaxil
>
>

Re: [VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Jarek Potiuk 
Fantastic!

On Thu, Apr 10, 2025 at 1:16 PM Vikram Koka 
wrote:

> Awesome!
>
> Thank you Kaxil and everyone who contributed to this release.
> Looking forward to testing this out and responding with my vote :)
>
> Vikram
>
> On Thu, Apr 10, 2025 at 9:53 AM Kaxil Naik  wrote:
>
> > Like last time, docker images are still building! I will email here once
> > they are published.
> >
> > On Thu, 10 Apr 2025 at 22:20, Kaxil Naik  wrote:
> >
> > > Hey fellow Airflowers,
> > >
> > > I am thrilled to announce the availability of Apache Airflow 3.0.0rc2 &
> > *Task
> > > SDK 1.0.0rc2* for testing!
> > >
> > > This email is calling for a vote on the release,
> > > which will last at least 7 days until 17th April.
> > > and until 3 binding +1 votes have been received.
> > >
> > > Consider this my (non-binding) +1.
> > >
> > > Airflow 3.0.0rc2 is available at:
> > > https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/
> > >
> > > "apache-airflow" Meta package:
> > >
> > >
> > >- *apache-airflow-3.0.0-source.tar.gz* is a source release that
> comes
> > >with INSTALL instructions.
> > >- *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist"
> release.
> > >- *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
> > >wheel "binary" release.
> > >
> > > "apache-airflow-core" package
> > >
> > >
> > >- *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
> > >release.
> > >- *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
> > >wheel "binary" release.
> > >
> > > Task SDK 1.0.0rc2 is available at:
> > > https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/
> > >
> > > "apache-airflow-task-sdk" package
> > >
> > >- *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
> > >- *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python
> "sdist"
> > >release.
> > >- *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary
> > >Python wheel "binary" release.
> > >
> > >
> > > Public keys are available at:
> > > https://dist.apache.org/repos/dist/release/airflow/KEYS
> > >
> > > Please vote accordingly:
> > >
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove with the reason
> > >
> > > Only votes from PMC members are binding, but all members of the
> community
> > > are encouraged to test the release and vote with "(non-binding)".
> > >
> > > The test procedure for PMC members is described in:
> > >
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
> > >
> > > The test procedure for contributors and members of the community who
> > would
> > > like to test this RC is described in:
> > >
> > >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
> > >
> > > Please note that the version number excludes the 'rcX' string, so it's
> > now
> > > simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will
> allow
> > > us to rename the artifact without modifying
> > > the artifact checksums when we actually release.
> > >
> > > Release Notes:
> > > https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst
> > >
> > >
> > > *Testing Instructions using PyPI*:
> > >
> > > You can build a virtualenv that installs this, and other required
> > packages
> > > (e.g. task sdk), like this:
> > >
> > > ```
> > >
> > > uv venv
> > >
> > > uv pip install apache-airflow --pre
> > >
> > > ```
> > >
> > > Get Involved
> > >
> > > We encourage the community to test this release and report any issues
> or
> > > feedback. Your contributions help us ensure a stable and reliable
> Airflow
> > > 3.0.0 release. Please report issues using Github at
> > > https://github.com/apache/airflow/issues and mark that this is an
> issue
> > > in 3.0.0. For an updated list of all known issues in the beta can also
> be
> > > found in the above link with the label “affected_version:3.0.0rc”
> > >
> > > A huge thank you to all the contributors who have worked on this
> > milestone
> > > release!
> > > Best,
> > > Kaxil
> > >
> > >
> >
>

[VOTE] Airflow Providers prepared on April 10, 2025

2025-04-10 Thread Elad Kalif 
Hey all,

I have just cut the new wave Airflow Providers packages. This email is
calling a vote on the release,
which will last for 72 hours - which means that it will end on April 13,
2025 14:45 PM UTC and until 3 binding +1 votes have been received.

Consider this my (binding) +1.

Airflow Providers are available at:
https://dist.apache.org/repos/dist/dev/airflow/providers/

*apache-airflow-providers--*.tar.gz* are the binary
 Python "sdist" release - they are also official "sources" for the Provider
distributions.

*apache_airflow_providers_-*.whl are the binary
 Python "wheel" release.

The test procedure for PMC members is described in
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDERS.md#verify-the-release-candidate-by-pmc-members

The test procedure for and Contributors who would like to test this RC is
described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDERS.md#verify-the-release-candidate-by-contributors


Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but members of the community are
encouraged to test the release and vote with "(non-binding)".

Please note that the version number excludes the 'rcX' string.
This will allow us to rename the artifact without modifying
the artifact checksums when we actually release.

The status of testing the providers by the community is kept here:
https://github.com/apache/airflow/issues/49066

The issue is also the easiest way to see important PRs included in the RC
candidates.
Detailed changelog for the providers will be published in the documentation
after the
RC candidates are released.

You can find the RC packages in PyPI following these links:

https://pypi.org/project/apache-airflow-providers-amazon/9.6.0rc1/
https://pypi.org/project/apache-airflow-providers-apache-hdfs/4.8.0rc1/
https://pypi.org/project/apache-airflow-providers-apache-livy/4.3.1rc1/
https://pypi.org/project/apache-airflow-providers-apache-spark/5.2.0rc1/
https://pypi.org/project/apache-airflow-providers-celery/3.10.6rc1/
https://pypi.org/project/apache-airflow-providers-cncf-kubernetes/10.4.2rc1/
https://pypi.org/project/apache-airflow-providers-common-io/1.5.3rc1/
https://pypi.org/project/apache-airflow-providers-common-messaging/1.0.0rc2/
https://pypi.org/project/apache-airflow-providers-databricks/7.3.1rc1/
https://pypi.org/project/apache-airflow-providers-discord/3.9.5rc1/
https://pypi.org/project/apache-airflow-providers-docker/4.3.1rc1/
https://pypi.org/project/apache-airflow-providers-fab/2.0.0rc4/
https://pypi.org/project/apache-airflow-providers-git/0.0.1rc1/
https://pypi.org/project/apache-airflow-providers-google/15.0.1rc1/
https://pypi.org/project/apache-airflow-providers-mysql/6.2.1rc1/
https://pypi.org/project/apache-airflow-providers-openlineage/2.1.3rc1/
https://pypi.org/project/apache-airflow-providers-sftp/5.2.0rc1/
https://pypi.org/project/apache-airflow-providers-slack/9.0.4rc1/
https://pypi.org/project/apache-airflow-providers-snowflake/6.2.1rc1/
https://pypi.org/project/apache-airflow-providers-sqlite/4.0.2rc1/
https://pypi.org/project/apache-airflow-providers-standard/0.4.0rc1/


Cheers,
Elad Kalif

[ANNOUNCE] Recording: April 2025 Airflow Monthly Town Hall

2025-04-10 Thread Briana Okyere 
Hey All,

Here is the recording from our April 2025 Airflow Town Hall! <
https://youtu.be/7CAkDE81nBs?si=gRSpqoq408NMIYZD
>

A big thanks to our speakers Savin Goyal, Buğra Öztürk, Amogh Desai, &
Rahul Gade!

Highlights included:
- Building Scalable ML Infrastructure with Airflow
- Optimizing Large-scale Deployments at LinkedIn
- & Top PRs of the Month

Reminder: Airflow Summit 2025 Super Early Bird Tickets are on sale!
https://airflow-summit--preview-2025-ainox3wv.web.app/tickets/


Briana Okyere

Re: [VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Vikram Koka 
Awesome!

Thank you Kaxil and everyone who contributed to this release.
Looking forward to testing this out and responding with my vote :)

Vikram

On Thu, Apr 10, 2025 at 9:53 AM Kaxil Naik  wrote:

> Like last time, docker images are still building! I will email here once
> they are published.
>
> On Thu, 10 Apr 2025 at 22:20, Kaxil Naik  wrote:
>
> > Hey fellow Airflowers,
> >
> > I am thrilled to announce the availability of Apache Airflow 3.0.0rc2 &
> *Task
> > SDK 1.0.0rc2* for testing!
> >
> > This email is calling for a vote on the release,
> > which will last at least 7 days until 17th April.
> > and until 3 binding +1 votes have been received.
> >
> > Consider this my (non-binding) +1.
> >
> > Airflow 3.0.0rc2 is available at:
> > https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/
> >
> > "apache-airflow" Meta package:
> >
> >
> >- *apache-airflow-3.0.0-source.tar.gz* is a source release that comes
> >with INSTALL instructions.
> >- *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist" release.
> >- *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
> >wheel "binary" release.
> >
> > "apache-airflow-core" package
> >
> >
> >- *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
> >release.
> >- *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
> >wheel "binary" release.
> >
> > Task SDK 1.0.0rc2 is available at:
> > https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/
> >
> > "apache-airflow-task-sdk" package
> >
> >- *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
> >- *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python "sdist"
> >release.
> >- *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary
> >Python wheel "binary" release.
> >
> >
> > Public keys are available at:
> > https://dist.apache.org/repos/dist/release/airflow/KEYS
> >
> > Please vote accordingly:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove with the reason
> >
> > Only votes from PMC members are binding, but all members of the community
> > are encouraged to test the release and vote with "(non-binding)".
> >
> > The test procedure for PMC members is described in:
> >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
> >
> > The test procedure for contributors and members of the community who
> would
> > like to test this RC is described in:
> >
> >
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
> >
> > Please note that the version number excludes the 'rcX' string, so it's
> now
> > simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will allow
> > us to rename the artifact without modifying
> > the artifact checksums when we actually release.
> >
> > Release Notes:
> > https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst
> >
> >
> > *Testing Instructions using PyPI*:
> >
> > You can build a virtualenv that installs this, and other required
> packages
> > (e.g. task sdk), like this:
> >
> > ```
> >
> > uv venv
> >
> > uv pip install apache-airflow --pre
> >
> > ```
> >
> > Get Involved
> >
> > We encourage the community to test this release and report any issues or
> > feedback. Your contributions help us ensure a stable and reliable Airflow
> > 3.0.0 release. Please report issues using Github at
> > https://github.com/apache/airflow/issues and mark that this is an issue
> > in 3.0.0. For an updated list of all known issues in the beta can also be
> > found in the above link with the label “affected_version:3.0.0rc”
> >
> > A huge thank you to all the contributors who have worked on this
> milestone
> > release!
> > Best,
> > Kaxil
> >
> >
>

[DISCUSS] Minimum versions of providers for Airflow 3

2025-04-10 Thread Jarek Potiuk 
Hello,

TL;DR; Do people who work on some providers think that Airflow 3 should
have minimum version of those?

While discussing a question about chicken-egg providers with Kaxil, I
realized that we can finally have min versions of providers easily added to
"apache-airflow" meta-package.

Simply speaking - we can say that for example

apache-airflow[openlineage] -> apache-airflow-providers-openlineage>=2.1.3

Previously it was not that easy or straightforward, but now we can do it
easily - just changing:

"openlineage" = [
"apache-airflow-providers-openlineage"
]
into

"openlineage" = [
"apache-airflow-providers-openlineage>=2.1.3"
]

We will likely have to change the tooling a bit to adapt to RC / Dev
packaging versions for chicken-egg-providers - but this should be rather
easy.

And I think this is mostly about openlineage, standard, common and all the
other kinds of providers that are "special" in some ways.

Are we aware of some minimum versions we **SHOULD** put on those ?

J.



So the question is.

setting up airflow on a cluster

2025-04-10 Thread Henry Tremblay 
I am looking for good documentation on setting up Apache Airflow on a
cluster. For the past 6 years, I have used a managed service (GCP
Composer). Currently, my current job is deploying Airflow locally on a
single server, with LocalExecutor.

I would like to explore setting this up on a cluster, perhaps with celery.

I have not found any good documentation on this.

Thanks!

-- 
Henry Tremblay
Data Engineer, Best Buy

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

2025-04-10 Thread Vincent Beck 
I assume this is not necessary when the constraint is already set on the 
provider side? For example, FAB provider has a dependency on Airflow 3 
(`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)

On 2025/04/10 17:22:13 Jarek Potiuk wrote:
> Hello,
> 
> TL;DR; Do people who work on some providers think that Airflow 3 should
> have minimum version of those?
> 
> While discussing a question about chicken-egg providers with Kaxil, I
> realized that we can finally have min versions of providers easily added to
> "apache-airflow" meta-package.
> 
> Simply speaking - we can say that for example
> 
> apache-airflow[openlineage] -> apache-airflow-providers-openlineage>=2.1.3
> 
> Previously it was not that easy or straightforward, but now we can do it
> easily - just changing:
> 
> "openlineage" = [
> "apache-airflow-providers-openlineage"
> ]
> into
> 
> "openlineage" = [
> "apache-airflow-providers-openlineage>=2.1.3"
> ]
> 
> We will likely have to change the tooling a bit to adapt to RC / Dev
> packaging versions for chicken-egg-providers - but this should be rather
> easy.
> 
> And I think this is mostly about openlineage, standard, common and all the
> other kinds of providers that are "special" in some ways.
> 
> Are we aware of some minimum versions we **SHOULD** put on those ?
> 
> J.
> 
> 
> 
> So the question is.
> 

-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

Re: Au revoir Flask

2025-04-10 Thread Pierre Jeambrun 
Nice job!

On Tue 8 Apr 2025 at 20:56, Buğra Öztürk  wrote:

> Amazing news Vincent! Great work!
>
> On Tue, 8 Apr 2025, 20:52 Ferruzzi, Dennis, 
> wrote:
>
> > Great work, all.
> >
> > > Yay! FABulous milestone!
> >
> > I believe you mean FAB-u-less?  :P
> >
> >
> >  - ferruzzi
> >
> >
> > 
> > From: Abhishek Bhakat 
> > Sent: Monday, April 7, 2025 10:54 PM
> > To: dev@airflow.apache.org
> > Subject: RE: [EXT] Au revoir Flask
> >
> > 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.
> >
> >
> >
> > Yay! FABulous milestone!
> >
> > On Tue, Apr 8, 2025 at 2:27 AM Amogh Desai 
> > wrote:
> >
> > > Awesome news Vincent!
> > >
> > > Thanks & Regards,
> > > Amogh Desai
> > >
> > >
> > > On Tue, Apr 8, 2025 at 6:58 AM Wei Lee  wrote:
> > >
> > > > This is nice!
> > > >
> > > > Best,
> > > > Wei
> > > >
> > > > > On Apr 8, 2025, at 3:35 AM, Vikram Koka
>  > >
> > > > wrote:
> > > > >
> > > > > Very cool!
> > > > >
> > > > > Great work here! Love the "FAB-light" state.
> > > > >
> > > > > On Mon, Apr 7, 2025 at 12:22 PM Jarek Potiuk 
> > wrote:
> > > > >
> > > > >> Cool. We are now FAB-light (not yet FAB-less, but that's still a
> > win).
> > > > >>
> > > > >> On Mon, Apr 7, 2025 at 3:11 PM Bishundeo, Rajeshwar
> > > > >>  wrote:
> > > > >>
> > > > >>> Wow. Major milestone in the history of Airflow. Great job
> Vincent,
> > > Jed,
> > > > >>> Jarek and everyone else involved!
> > > > >>>
> > > > >>> -- Rajesh
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 2025-04-07, 3:09 PM, "Beck, Vincent"
>  > > > >>> LID> wrote:
> > > > >>>
> > > > >>>
> > > > >>> 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.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Hi all,
> > > > >>>
> > > > >>>
> > > > >>> Just a quick FYI — PR #48457 (
> > > > >> https://github.com/apache/airflow/pull/48457
> > > > >>> ), which removes
> the
> > > > Flask
> > > > >>> AppBuilder (FAB) provider from the preinstalled providers, has
> just
> > > > been
> > > > >>> merged. This marks the successful completion of AIP-79! 🎉
> > > > >>>
> > > > >>>
> > > > >>> Going forward, unless you explicitly install the FAB provider as
> an
> > > > >> extra,
> > > > >>> Flask is no longer a core dependency of Airflow.
> > > > >>>
> > > > >>>
> > > > >>> Huge thanks to everyone who contributed along the way — with a
> > > special
> > > > >>> shout-out to Jarek for consistently providing help with questions
> > and
> > > > >>> tricky issues, and of course to Jed, who initiated the AIP and
> put
> > in
> > > > an
> > > > >>> immense amount of work to see it through.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Thanks again to all involved!
> > > > >>>
> > > > >>>
> > > > >>> Vincent
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> > > > For additional commands, e-mail: dev-h...@airflow.apache.org
> > > >
> > > >
> > >
> >
>

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

2025-04-10 Thread Jarek Potiuk 
Accidentally It turned out - with today's investigation of why RC images
are not building that it is VERY needed. It seems that `pip` resolution
works currently with our meta-package in a very bad way. If in our
pyproject.toml we have just
"amazon' =  "apache-airflow-providers-amazon", "google" =
"apache-airflow-providers-google" 

then

apache-airflow[google,amazon] - will lead pip to download and try to
resolve ALL VERSIONS or apparently ALL providers that have ever been
released. That means we have 100 amazon, 100 google - and if you have more
extras - 10s or 100s of other providers to consider. And essentially what
pip tries to do is - try all combinations of those to find out which ones
are good. Or at least very, very big subset of those providers. Which
actually explains the "Resolution Too Deep" problem we tried to diagnose
and investigate over the last few weeks.

So summarising:
* resolution too deep was actually "real" issue
* it was caused by no lower-bounds in providers in meta package
* we will have to set those lower-binds to something reasonable (and I
might start later today with simply latest released versions if i have
internet on my flight back from the US)
* and we will have to keep those min versions updated and bumped
periodically

The last case is interesting - because it will finally force us to
introduce some policy on how old providers we support when we release
airflow. With Airflow 3 I think we are good with basically "latest"
versions (and maybe get a few versions back for crucial providers). But we
can discuss it later.

J.





On Thu, Apr 10, 2025 at 2:49 PM Vincent Beck  wrote:

> I assume this is not necessary when the constraint is already set on the
> provider side? For example, FAB provider has a dependency on Airflow 3
> (`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)
>
> On 2025/04/10 17:22:13 Jarek Potiuk wrote:
> > Hello,
> >
> > TL;DR; Do people who work on some providers think that Airflow 3 should
> > have minimum version of those?
> >
> > While discussing a question about chicken-egg providers with Kaxil, I
> > realized that we can finally have min versions of providers easily added
> to
> > "apache-airflow" meta-package.
> >
> > Simply speaking - we can say that for example
> >
> > apache-airflow[openlineage] ->
> apache-airflow-providers-openlineage>=2.1.3
> >
> > Previously it was not that easy or straightforward, but now we can do it
> > easily - just changing:
> >
> > "openlineage" = [
> > "apache-airflow-providers-openlineage"
> > ]
> > into
> >
> > "openlineage" = [
> > "apache-airflow-providers-openlineage>=2.1.3"
> > ]
> >
> > We will likely have to change the tooling a bit to adapt to RC / Dev
> > packaging versions for chicken-egg-providers - but this should be rather
> > easy.
> >
> > And I think this is mostly about openlineage, standard, common and all
> the
> > other kinds of providers that are "special" in some ways.
> >
> > Are we aware of some minimum versions we **SHOULD** put on those ?
> >
> > J.
> >
> >
> >
> > So the question is.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
>
>

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

2025-04-10 Thread Ash Berlin-Taylor 
There absolutely is a downside to the users — “forcing" users to upgrade 
providers along with Airflow version makes upgrades a much more daunting 
experience.

> On 10 Apr 2025, at 21:31, Maciej Obuchowski  wrote:
> 
> For OpenLineage we'd definitely like something like this.
> IMO there is no downside to restricting the providers to the latest
> released version.
> We could go with the chicken-egg for the next release - that would add at
> least one useful
> feature authored by Kacper Muda -
> https://github.com/apache/airflow/pull/48941
> but even without it it's not broken, just missing that feature.
> 
> 
> czw., 10 kwi 2025 o 21:49 Jarek Potiuk  napisał(a):
> 
>> Accidentally It turned out - with today's investigation of why RC images
>> are not building that it is VERY needed. It seems that `pip` resolution
>> works currently with our meta-package in a very bad way. If in our
>> pyproject.toml we have just
>> "amazon' =  "apache-airflow-providers-amazon", "google" =
>> "apache-airflow-providers-google" 
>> 
>> then
>> 
>> apache-airflow[google,amazon] - will lead pip to download and try to
>> resolve ALL VERSIONS or apparently ALL providers that have ever been
>> released. That means we have 100 amazon, 100 google - and if you have more
>> extras - 10s or 100s of other providers to consider. And essentially what
>> pip tries to do is - try all combinations of those to find out which ones
>> are good. Or at least very, very big subset of those providers. Which
>> actually explains the "Resolution Too Deep" problem we tried to diagnose
>> and investigate over the last few weeks.
>> 
>> So summarising:
>> * resolution too deep was actually "real" issue
>> * it was caused by no lower-bounds in providers in meta package
>> * we will have to set those lower-binds to something reasonable (and I
>> might start later today with simply latest released versions if i have
>> internet on my flight back from the US)
>> * and we will have to keep those min versions updated and bumped
>> periodically
>> 
>> The last case is interesting - because it will finally force us to
>> introduce some policy on how old providers we support when we release
>> airflow. With Airflow 3 I think we are good with basically "latest"
>> versions (and maybe get a few versions back for crucial providers). But we
>> can discuss it later.
>> 
>> J.
>> 
>> 
>> 
>> 
>> 
>> On Thu, Apr 10, 2025 at 2:49 PM Vincent Beck  wrote:
>> 
>>> I assume this is not necessary when the constraint is already set on the
>>> provider side? For example, FAB provider has a dependency on Airflow 3
>>> (`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)
>>> 
>>> On 2025/04/10 17:22:13 Jarek Potiuk wrote:
 Hello,
 
 TL;DR; Do people who work on some providers think that Airflow 3 should
 have minimum version of those?
 
 While discussing a question about chicken-egg providers with Kaxil, I
 realized that we can finally have min versions of providers easily
>> added
>>> to
 "apache-airflow" meta-package.
 
 Simply speaking - we can say that for example
 
 apache-airflow[openlineage] ->
>>> apache-airflow-providers-openlineage>=2.1.3
 
 Previously it was not that easy or straightforward, but now we can do
>> it
 easily - just changing:
 
 "openlineage" = [
"apache-airflow-providers-openlineage"
 ]
 into
 
 "openlineage" = [
"apache-airflow-providers-openlineage>=2.1.3"
 ]
 
 We will likely have to change the tooling a bit to adapt to RC / Dev
 packaging versions for chicken-egg-providers - but this should be
>> rather
 easy.
 
 And I think this is mostly about openlineage, standard, common and all
>>> the
 other kinds of providers that are "special" in some ways.
 
 Are we aware of some minimum versions we **SHOULD** put on those ?
 
 J.
 
 
 
 So the question is.
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
>>> For additional commands, e-mail: dev-h...@airflow.apache.org
>>> 
>>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

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

2025-04-10 Thread Maciej Obuchowski 
For OpenLineage we'd definitely like something like this.
IMO there is no downside to restricting the providers to the latest
released version.
We could go with the chicken-egg for the next release - that would add at
least one useful
feature authored by Kacper Muda -
https://github.com/apache/airflow/pull/48941
but even without it it's not broken, just missing that feature.


czw., 10 kwi 2025 o 21:49 Jarek Potiuk  napisał(a):

> Accidentally It turned out - with today's investigation of why RC images
> are not building that it is VERY needed. It seems that `pip` resolution
> works currently with our meta-package in a very bad way. If in our
> pyproject.toml we have just
> "amazon' =  "apache-airflow-providers-amazon", "google" =
> "apache-airflow-providers-google" 
>
> then
>
> apache-airflow[google,amazon] - will lead pip to download and try to
> resolve ALL VERSIONS or apparently ALL providers that have ever been
> released. That means we have 100 amazon, 100 google - and if you have more
> extras - 10s or 100s of other providers to consider. And essentially what
> pip tries to do is - try all combinations of those to find out which ones
> are good. Or at least very, very big subset of those providers. Which
> actually explains the "Resolution Too Deep" problem we tried to diagnose
> and investigate over the last few weeks.
>
> So summarising:
> * resolution too deep was actually "real" issue
> * it was caused by no lower-bounds in providers in meta package
> * we will have to set those lower-binds to something reasonable (and I
> might start later today with simply latest released versions if i have
> internet on my flight back from the US)
> * and we will have to keep those min versions updated and bumped
> periodically
>
> The last case is interesting - because it will finally force us to
> introduce some policy on how old providers we support when we release
> airflow. With Airflow 3 I think we are good with basically "latest"
> versions (and maybe get a few versions back for crucial providers). But we
> can discuss it later.
>
> J.
>
>
>
>
>
> On Thu, Apr 10, 2025 at 2:49 PM Vincent Beck  wrote:
>
> > I assume this is not necessary when the constraint is already set on the
> > provider side? For example, FAB provider has a dependency on Airflow 3
> > (`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)
> >
> > On 2025/04/10 17:22:13 Jarek Potiuk wrote:
> > > Hello,
> > >
> > > TL;DR; Do people who work on some providers think that Airflow 3 should
> > > have minimum version of those?
> > >
> > > While discussing a question about chicken-egg providers with Kaxil, I
> > > realized that we can finally have min versions of providers easily
> added
> > to
> > > "apache-airflow" meta-package.
> > >
> > > Simply speaking - we can say that for example
> > >
> > > apache-airflow[openlineage] ->
> > apache-airflow-providers-openlineage>=2.1.3
> > >
> > > Previously it was not that easy or straightforward, but now we can do
> it
> > > easily - just changing:
> > >
> > > "openlineage" = [
> > > "apache-airflow-providers-openlineage"
> > > ]
> > > into
> > >
> > > "openlineage" = [
> > > "apache-airflow-providers-openlineage>=2.1.3"
> > > ]
> > >
> > > We will likely have to change the tooling a bit to adapt to RC / Dev
> > > packaging versions for chicken-egg-providers - but this should be
> rather
> > > easy.
> > >
> > > And I think this is mostly about openlineage, standard, common and all
> > the
> > > other kinds of providers that are "special" in some ways.
> > >
> > > Are we aware of some minimum versions we **SHOULD** put on those ?
> > >
> > > J.
> > >
> > >
> > >
> > > So the question is.
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> > For additional commands, e-mail: dev-h...@airflow.apache.org
> >
> >
>

Re: Au revoir Flask

2025-04-10 Thread Buğra Öztürk 
Amazing news Vincent! Great work!

On Tue, 8 Apr 2025, 20:52 Ferruzzi, Dennis, 
wrote:

> Great work, all.
>
> > Yay! FABulous milestone!
>
> I believe you mean FAB-u-less?  :P
>
>
>  - ferruzzi
>
>
> 
> From: Abhishek Bhakat 
> Sent: Monday, April 7, 2025 10:54 PM
> To: dev@airflow.apache.org
> Subject: RE: [EXT] Au revoir Flask
>
> 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.
>
>
>
> Yay! FABulous milestone!
>
> On Tue, Apr 8, 2025 at 2:27 AM Amogh Desai 
> wrote:
>
> > Awesome news Vincent!
> >
> > Thanks & Regards,
> > Amogh Desai
> >
> >
> > On Tue, Apr 8, 2025 at 6:58 AM Wei Lee  wrote:
> >
> > > This is nice!
> > >
> > > Best,
> > > Wei
> > >
> > > > On Apr 8, 2025, at 3:35 AM, Vikram Koka  >
> > > wrote:
> > > >
> > > > Very cool!
> > > >
> > > > Great work here! Love the "FAB-light" state.
> > > >
> > > > On Mon, Apr 7, 2025 at 12:22 PM Jarek Potiuk 
> wrote:
> > > >
> > > >> Cool. We are now FAB-light (not yet FAB-less, but that's still a
> win).
> > > >>
> > > >> On Mon, Apr 7, 2025 at 3:11 PM Bishundeo, Rajeshwar
> > > >>  wrote:
> > > >>
> > > >>> Wow. Major milestone in the history of Airflow. Great job Vincent,
> > Jed,
> > > >>> Jarek and everyone else involved!
> > > >>>
> > > >>> -- Rajesh
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On 2025-04-07, 3:09 PM, "Beck, Vincent"  > > >>> LID> wrote:
> > > >>>
> > > >>>
> > > >>> 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.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Hi all,
> > > >>>
> > > >>>
> > > >>> Just a quick FYI — PR #48457 (
> > > >> https://github.com/apache/airflow/pull/48457
> > > >>> ), which removes the
> > > Flask
> > > >>> AppBuilder (FAB) provider from the preinstalled providers, has just
> > > been
> > > >>> merged. This marks the successful completion of AIP-79! 🎉
> > > >>>
> > > >>>
> > > >>> Going forward, unless you explicitly install the FAB provider as an
> > > >> extra,
> > > >>> Flask is no longer a core dependency of Airflow.
> > > >>>
> > > >>>
> > > >>> Huge thanks to everyone who contributed along the way — with a
> > special
> > > >>> shout-out to Jarek for consistently providing help with questions
> and
> > > >>> tricky issues, and of course to Jed, who initiated the AIP and put
> in
> > > an
> > > >>> immense amount of work to see it through.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Thanks again to all involved!
> > > >>>
> > > >>>
> > > >>> Vincent
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> > > For additional commands, e-mail: dev-h...@airflow.apache.org
> > >
> > >
> >
>

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

2025-04-10 Thread Jarek Potiuk 
Actually what I see when I attempted to do it - is that even if we
introduce it - it is not going to be a hard requirement. It is just a soft
limit when installing full apache-airflow[with extras].

It will be more of a default behaviour to limit the providers when extras
are used but will be easy to override and it will not apply when you
install airflow-core /task-sdk/ providers directly. So yes - I think no
real drawback

This limits will only be on extras of the 'apache-airflow' and in case
someone used the extras so far - the were not able to control the version
of provider that will be used anyway - and this only used a lower version
of provider than latest I'd some other package was installed at the same
time that was conflicting with latest provider..

Thoss limits are not going to be persistent, they are going to simply be
taken into account when apache-airflow{provider} is used and only for the
time of the installation. It will not prevent the user from
upgrading/downgrading the provider later. And also user still be able to
remove extra and use the provider directly in the same `pip install`
command

I have a draft change that sets the lower bound to now() -6 months + manual
overrides if we need to get some new provider limited to latest version
this way for example. I am still coming back from US and will be home later
today and try it and I think some form of it will be good to have  - 6
months seems reasonable and it will have the 'self-maintenance' capability.

J.

czw., 10 kwi 2025, 22:46 użytkownik Ash Berlin-Taylor 
napisał:

> There absolutely is a downside to the users — “forcing" users to upgrade
> providers along with Airflow version makes upgrades a much more daunting
> experience.
>
> > On 10 Apr 2025, at 21:31, Maciej Obuchowski 
> wrote:
> >
> > For OpenLineage we'd definitely like something like this.
> > IMO there is no downside to restricting the providers to the latest
> > released version.
> > We could go with the chicken-egg for the next release - that would add at
> > least one useful
> > feature authored by Kacper Muda -
> > https://github.com/apache/airflow/pull/48941
> > but even without it it's not broken, just missing that feature.
> >
> >
> > czw., 10 kwi 2025 o 21:49 Jarek Potiuk  napisał(a):
> >
> >> Accidentally It turned out - with today's investigation of why RC images
> >> are not building that it is VERY needed. It seems that `pip` resolution
> >> works currently with our meta-package in a very bad way. If in our
> >> pyproject.toml we have just
> >> "amazon' =  "apache-airflow-providers-amazon", "google" =
> >> "apache-airflow-providers-google" 
> >>
> >> then
> >>
> >> apache-airflow[google,amazon] - will lead pip to download and try to
> >> resolve ALL VERSIONS or apparently ALL providers that have ever been
> >> released. That means we have 100 amazon, 100 google - and if you have
> more
> >> extras - 10s or 100s of other providers to consider. And essentially
> what
> >> pip tries to do is - try all combinations of those to find out which
> ones
> >> are good. Or at least very, very big subset of those providers. Which
> >> actually explains the "Resolution Too Deep" problem we tried to diagnose
> >> and investigate over the last few weeks.
> >>
> >> So summarising:
> >> * resolution too deep was actually "real" issue
> >> * it was caused by no lower-bounds in providers in meta package
> >> * we will have to set those lower-binds to something reasonable (and I
> >> might start later today with simply latest released versions if i have
> >> internet on my flight back from the US)
> >> * and we will have to keep those min versions updated and bumped
> >> periodically
> >>
> >> The last case is interesting - because it will finally force us to
> >> introduce some policy on how old providers we support when we release
> >> airflow. With Airflow 3 I think we are good with basically "latest"
> >> versions (and maybe get a few versions back for crucial providers). But
> we
> >> can discuss it later.
> >>
> >> J.
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Apr 10, 2025 at 2:49 PM Vincent Beck 
> wrote:
> >>
> >>> I assume this is not necessary when the constraint is already set on
> the
> >>> provider side? For example, FAB provider has a dependency on Airflow 3
> >>> (`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)
> >>>
> >>> On 2025/04/10 17:22:13 Jarek Potiuk wrote:
>  Hello,
> 
>  TL;DR; Do people who work on some providers think that Airflow 3
> should
>  have minimum version of those?
> 
>  While discussing a question about chicken-egg providers with Kaxil, I
>  realized that we can finally have min versions of providers easily
> >> added
> >>> to
>  "apache-airflow" meta-package.
> 
>  Simply speaking - we can say that for example
> 
>  apache-airflow[openlineage] ->
> >>> apache-airflow-providers-openlineage>=2.1.3
> 
>  Previously it was not that easy or straightforward, but now we can do
>

Re: [VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Ash Berlin-Taylor 
Most of the docker images for rc2 are now published on docker hub:

Apache/airflow:slim-3.0.0rc2-python3.10
apache/airflow:slim-3.0.0rc2-python3.11
apache/airflow:slim-3.0.0rc2-python3.12
apache/airflow:3.0.0rc2-python3.10
apache/airflow:3.0.0rc2-python3.11
apache/airflow:3.0.0rc2-python3.12

The 3.9 image haven’t yet completed, so these aren’t available yet.

apache/airflow:slim-3.0.0rc2-python3.9
apache/airflow:3.0.0rc2-python3.9

Enjoy!
-ash

> On 10 Apr 2025, at 18:16, Jarek Potiuk  wrote:
> 
> Fantastic!
> 
> On Thu, Apr 10, 2025 at 1:16 PM Vikram Koka 
> wrote:
> 
>> Awesome!
>> 
>> Thank you Kaxil and everyone who contributed to this release.
>> Looking forward to testing this out and responding with my vote :)
>> 
>> Vikram
>> 
>> On Thu, Apr 10, 2025 at 9:53 AM Kaxil Naik  wrote:
>> 
>>> Like last time, docker images are still building! I will email here once
>>> they are published.
>>> 
>>> On Thu, 10 Apr 2025 at 22:20, Kaxil Naik  wrote:
>>> 
 Hey fellow Airflowers,
 
 I am thrilled to announce the availability of Apache Airflow 3.0.0rc2 &
>>> *Task
 SDK 1.0.0rc2* for testing!
 
 This email is calling for a vote on the release,
 which will last at least 7 days until 17th April.
 and until 3 binding +1 votes have been received.
 
 Consider this my (non-binding) +1.
 
 Airflow 3.0.0rc2 is available at:
 https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/
 
 "apache-airflow" Meta package:
 
 
   - *apache-airflow-3.0.0-source.tar.gz* is a source release that
>> comes
   with INSTALL instructions.
   - *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist"
>> release.
   - *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
   wheel "binary" release.
 
 "apache-airflow-core" package
 
 
   - *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
   release.
   - *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
   wheel "binary" release.
 
 Task SDK 1.0.0rc2 is available at:
 https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/
 
 "apache-airflow-task-sdk" package
 
   - *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
   - *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python
>> "sdist"
   release.
   - *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary
   Python wheel "binary" release.
 
 
 Public keys are available at:
 https://dist.apache.org/repos/dist/release/airflow/KEYS
 
 Please vote accordingly:
 
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 disapprove with the reason
 
 Only votes from PMC members are binding, but all members of the
>> community
 are encouraged to test the release and vote with "(non-binding)".
 
 The test procedure for PMC members is described in:
 
 
>>> 
>> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
 
 The test procedure for contributors and members of the community who
>>> would
 like to test this RC is described in:
 
 
>>> 
>> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
 
 Please note that the version number excludes the 'rcX' string, so it's
>>> now
 simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will
>> allow
 us to rename the artifact without modifying
 the artifact checksums when we actually release.
 
 Release Notes:
 https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst
 
 
 *Testing Instructions using PyPI*:
 
 You can build a virtualenv that installs this, and other required
>>> packages
 (e.g. task sdk), like this:
 
 ```
 
 uv venv
 
 uv pip install apache-airflow --pre
 
 ```
 
 Get Involved
 
 We encourage the community to test this release and report any issues
>> or
 feedback. Your contributions help us ensure a stable and reliable
>> Airflow
 3.0.0 release. Please report issues using Github at
 https://github.com/apache/airflow/issues and mark that this is an
>> issue
 in 3.0.0. For an updated list of all known issues in the beta can also
>> be
 found in the above link with the label “affected_version:3.0.0rc”
 
 A huge thank you to all the contributors who have worked on this
>>> milestone
 release!
 Best,
 Kaxil
 
 
>>> 
>>

Re: [VOTE] Release Airflow 3.0.0 from 3.0.0rc2 & Task SDK 1.0.0 from 1.0.0rc2

2025-04-10 Thread Vikram Koka 
Very cool. Thanks for working through this, Ash!

On Thu, Apr 10, 2025 at 2:41 PM Ash Berlin-Taylor  wrote:

> Most of the docker images for rc2 are now published on docker hub:
>
> Apache/airflow:slim-3.0.0rc2-python3.10
> apache/airflow:slim-3.0.0rc2-python3.11
> apache/airflow:slim-3.0.0rc2-python3.12
> apache/airflow:3.0.0rc2-python3.10
> apache/airflow:3.0.0rc2-python3.11
> apache/airflow:3.0.0rc2-python3.12
>
> The 3.9 image haven’t yet completed, so these aren’t available yet.
>
> apache/airflow:slim-3.0.0rc2-python3.9
> apache/airflow:3.0.0rc2-python3.9
>
> Enjoy!
> -ash
>
> > On 10 Apr 2025, at 18:16, Jarek Potiuk  wrote:
> >
> > Fantastic!
> >
> > On Thu, Apr 10, 2025 at 1:16 PM Vikram Koka  >
> > wrote:
> >
> >> Awesome!
> >>
> >> Thank you Kaxil and everyone who contributed to this release.
> >> Looking forward to testing this out and responding with my vote :)
> >>
> >> Vikram
> >>
> >> On Thu, Apr 10, 2025 at 9:53 AM Kaxil Naik  wrote:
> >>
> >>> Like last time, docker images are still building! I will email here
> once
> >>> they are published.
> >>>
> >>> On Thu, 10 Apr 2025 at 22:20, Kaxil Naik  wrote:
> >>>
>  Hey fellow Airflowers,
> 
>  I am thrilled to announce the availability of Apache Airflow 3.0.0rc2
> &
> >>> *Task
>  SDK 1.0.0rc2* for testing!
> 
>  This email is calling for a vote on the release,
>  which will last at least 7 days until 17th April.
>  and until 3 binding +1 votes have been received.
> 
>  Consider this my (non-binding) +1.
> 
>  Airflow 3.0.0rc2 is available at:
>  https://dist.apache.org/repos/dist/dev/airflow/3.0.0rc2/
> 
>  "apache-airflow" Meta package:
> 
> 
>    - *apache-airflow-3.0.0-source.tar.gz* is a source release that
> >> comes
>    with INSTALL instructions.
>    - *apache-airflow-3.0.0.tar.gz* is the binary Python "sdist"
> >> release.
>    - *apache_airflow-3.0.0-py3-none-any.whl* is the binary Python
>    wheel "binary" release.
> 
>  "apache-airflow-core" package
> 
> 
>    - *apache_airflow_core-3.0.0.tar.gz* is the binary Python "sdist"
>    release.
>    - *apache_airflow_3.0.0-py3-none-any.whl* is the binary Python
>    wheel "binary" release.
> 
>  Task SDK 1.0.0rc2 is available at:
>  https://dist.apache.org/repos/dist/dev/airflow/task-sdk/1.0.0rc2/
> 
>  "apache-airflow-task-sdk" package
> 
>    - *apache-airflow-task-sdk-1.0.0-source.tar.gz* is a source release
>    - *apache_airflow_task_sdk-1.0.0.tar.gz* is the binary Python
> >> "sdist"
>    release.
>    - *apache_airflow_task_sdk-1.0.0-py3-none-any.whl* is the binary
>    Python wheel "binary" release.
> 
> 
>  Public keys are available at:
>  https://dist.apache.org/repos/dist/release/airflow/KEYS
> 
>  Please vote accordingly:
> 
>  [ ] +1 approve
>  [ ] +0 no opinion
>  [ ] -1 disapprove with the reason
> 
>  Only votes from PMC members are binding, but all members of the
> >> community
>  are encouraged to test the release and vote with "(non-binding)".
> 
>  The test procedure for PMC members is described in:
> 
> 
> >>>
> >>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-pmc-members
> 
>  The test procedure for contributors and members of the community who
> >>> would
>  like to test this RC is described in:
> 
> 
> >>>
> >>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md\#verify-the-release-candidate-by-contributors
> 
>  Please note that the version number excludes the 'rcX' string, so it's
> >>> now
>  simply 3.0.0 for Airflow package and 1.0.0 for Task SDK. This will
> >> allow
>  us to rename the artifact without modifying
>  the artifact checksums when we actually release.
> 
>  Release Notes:
>  https://github.com/apache/airflow/blob/3.0.0rc2/RELEASE_NOTES.rst
> 
> 
>  *Testing Instructions using PyPI*:
> 
>  You can build a virtualenv that installs this, and other required
> >>> packages
>  (e.g. task sdk), like this:
> 
>  ```
> 
>  uv venv
> 
>  uv pip install apache-airflow --pre
> 
>  ```
> 
>  Get Involved
> 
>  We encourage the community to test this release and report any issues
> >> or
>  feedback. Your contributions help us ensure a stable and reliable
> >> Airflow
>  3.0.0 release. Please report issues using Github at
>  https://github.com/apache/airflow/issues and mark that this is an
> >> issue
>  in 3.0.0. For an updated list of all known issues in the beta can also
> >> be
>  found in the above link with the label “affected_version:3.0.0rc”
> 
>  A huge thank you to all the contributors who have worked on this
> >>> milestone
>  release!
>  Best,
>  Kaxil
> 
> 
> >>>
>

[RESULT][VOTE] Airflow Providers - April 06, 2025

2025-04-10 Thread Elad Kalif 
Hello,

Apache Airflow Providers prepared on April 06, 2025 have been accepted.
fab and common.messaging providers are excluded from this wave thus not
counting votes on it.

3 "+1" binding votes received:
- Elad Kalif
- Jens Scheffler
- Jarek Potiuk

1 "+1" non-binding votes received:
- Pankaj Koti
- Vishnu Chilukoori
- Amogh Desai

Vote thread:
https://lists.apache.org/thread/hn9wfcpw04t0t45onxovbz74mlz3nyp7

I'll continue with the release process, and the release announcement will
follow shortly.

Cheers,
Elad Kalif