Re: Naming things: What should the imports in dag files for DAG etc. be?

Yes, strongly agreed on the “no side-effects form `import airflow`”. To summarise the options so far: 1. `from airflow import DAG, TaskGroup` — have the imports be from the top level airflow module 2. `from airflow.definitions import DAG, TaskGroup` 3. `from airflow.sdk import DAG, TaskGroup` >

Re: Naming things: What should the imports in dag files for DAG etc. be?

Yep so. If we do not have side-effects from import airflow -> my vote would be "airflow.sdk" :) On Mon, Sep 2, 2024 at 10:29 AM Ash Berlin-Taylor wrote: > Yes, strongly agreed on the “no side-effects form `import airflow`”. > > To summarise the options so far: > > 1. `from airflow import DAG, Ta

[VOTE] Release Airflow 2.10.1 from 2.10.1rc1

Hey fellow Airflowers, I have cut Airflow 2.10.1rc1. This email is calling for a vote on the release, which will last at least 72 hours, from Tuesday, September 3, 2024, at 2:30 AM UTC until Friday, September 6, 2024, at 2:30 AM UTC

Re: [VOTE] Release Airflow 2.10.1 from 2.10.1rc1

+1 non binding I managed to test my changes #41783 , #41680 , #41694 , #41890 and all of them work as expected.

Re: [VOTE] Release Airflow 2.10.1 from 2.10.1rc1

+1 (binding) - tested reproducibility, checksums, signatures, licences, run a few DAGs with it, installed on various Python versions (plugins manager deprecation warning gone in Python 3.12). Re: Amogh comment - > created an issue to improve "Status of the issue" generation to better handle backpo