I understand the concern, but would also wonder that a code base, be it user DAGs or third-party operators, lacks support in such a way, they would be correct to not encourage users to upgrade anyway. Airflow 3 is already going to have various breakages, some of them significantly less obvious than this change.
IMO we should not aim for trying to treat the number of people being able to upgrade as an absolute metric. That’s another thing I observed from other projects. No matter how hard to try, you are going to break a lot of things when you do a major version upgrade; if the goal is to minimise things you break, the only reasonable decision is to never do a major version bump (in the semantic versioning sense). If you decide to bump the major version, the best thing you can do is to draw a line in the sand, mark the breakages as clearly as possible, and provide a good compatible layer, so the users (both second and third parties) can make an informed decision when not to upgrade themselves, at their own pace. I respect all the concerns raised here. They are all true. I would also predict that they will still all happen, regardless of this AIP. The only other way is to never rock the boat, and be contempt with Airflow 3 being just Airflow 2 with new decorations. It’s a valid approach to take too. TP > On 26 Jul 2024, at 04:55, Michał Modras <michalmod...@google.com.INVALID> > wrote: > > -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. >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
