-1 (non-binding) While the cleaner approach to templates is appealing, the blast radius of this change in its current shape is enormous. I am worried that it would strongly impede migration of users from Airflow 2 to Airflow 3, especially that not all Airflow users are proficient in Airflow, and for some organizations it could be a no-go. Another consequence is that thousands of operators in provider packages would need to be migrated, which would be a significant effort to the Airflow community, and it would take time. Potential lack of support of some operators / providers (until they are migrated themselves) would not encourage users to migrate to Airflow 3 neither. Perhaps a more optional approach could be considered to enable more gradual adoption of the functionality?
On Thu, Jul 25, 2024 at 10:35 PM Jarek Potiuk <ja...@potiuk.com> wrote: > I am personally perfectly fine with that approach. Looks like a good design > for the approach when we decide that "breaking most DAGs is acceptable" > in general. > > J. >
