For whatever reason, I was reminded recently of snowflake's "behavior change" policy
See here: https://docs.snowflake.com/en/release-notes/behavior-change-policy I think semver is problematic for core because basically you cannot implement behavior changes until the "mythical" major release. The next major always seems very far off. Indeed some have suggested that 3.0 might never happen (looking at you @potiuk :) ). Given the fact that it is so incredibly uncertain when exactly 3.0 will happen (and after that, subsequent major releases), it really makes the developer's job a lot harder. Because you feel like you may never (or practically never) be able to make a change, or fix something, etc. What snowflake does is they release "behavior changes" (a.k.a. breaks with backward compatibility) in phases. First is testing phase (users can enable optionally). Next is opt-out period (enabled by default but you can disable). Final phase is general availability, when it's enabled and you can't disable it. Moving to something like this would give us a little more flexibility to evolve airflow incrementally over time, without putting so much pressure on those mythical major releases. And it would not put so much pressure on individual feature development, because you would know that there's a reasonable path to changing things down the road. Because of the infrequency of our major releases, I really think for core, semver is just not working for us. That's perhaps a bold claim, but that's how I feel. Discuss!
