And to clarify, when I talk about putting pressure on major releases, what I mean is that there's this notion that a major release has to have some very special or big feature change. One reason offered is marketing. Major release is an opportunity to market airflow, so take advantage of that. Another offered is, "well folks won't upgrade if there's not some special carrots in it", especially given that major releases are where we introduce a bunch of breaking changes all at once.
Well, if we had a different policy that allowed for introducing behavior changes on a regular basis, then we would not have to save them all up for the major release, and unleash them on the users all at once. So then you would not have that big painful major release upgrade to deal with -- you'd have done it a little bit at a time. So the "carrots" become less important perhaps. Perhaps the fact that behavior changes would come out in dribs and drabs over time would make it more likely for users to upgrade sooner, because staying current would be less painful than getting too far behind -- though that's just a thought. But anyway, the way it is now, the major release seems to be too many things: big marketing push, tons of new features, *and* the only opportunity to make breaking changes. A policy like snowflake's seems so much healthier, methodical, and relaxed, allowing us to be selective about when and how to release behavior changes, without it having to be anything more than that. CalVer <https://calver.org/> may be a good option. On Sat, Aug 26, 2023 at 11:22 PM Daniel Standish < daniel.stand...@astronomer.io> wrote: > 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! > > > > >
