I don't think *one size fits all approach* will work with Providers. The wait for X months without a major version won't be possible to achieve in cases where we need to bump dependencies of providers that break things too. (example Google provider 3.0.0 -> 4.0.0)
If users were caught by surprise with breaking changes in major versions, then maybe the other major versions we released were "not breaking". Instead of adding tons of policies, sticking by SemVer and bumping major versions only when we have breaking changes for *providers* is what I recommend as well. In Rafal's case, this was the issue because the fixes that were clubbed with Google Provider might have been critical or major. I just say in cases like those we assess and help the community by releasing a patch version of the previous release by assessing if that's possible and for stakeholders to just look at the changes when we are in the voting phase. This should be a comparatively rare occurrence. Regards, Kaxil On Sat, 21 May 2022 at 19:24, Jarek Potiuk <[email protected]> wrote: > And about this > > > By "policy for policy's sake" this is exactly what I mean - we have so > much work down already it feels nigh on impossible to know everything. > > BTW. I see it differently. We have policies, precisely because we are > not able to follow everything, so we write policies that anyone who is > a committer can follow - without getting approvals or discussing it > with others. We should have those policies done in the way that anyone > who is in the project knows what to do without making any assumptions > :). So if we feel overwhelmed with decisions - we should have more > precise policies so that - we do not have to make the decisions next > time when we get there. That's why I think we should codify all the > rules we follow - especially when this impacts our users. > > And I think it is super important that our users know what to expect from > us :). > > > But it's a sign to the users that something has broken. If you want to > wait six months feel free. But I don't think that should be our policy. I > the policy to be "we release under SemVer so can delete code that was > deprecated under the previous major version". No time requirement. > > Following the above. Are you proposing we make it as a rule? Always > remove all deprecation with any breaking release of every provider? I > think our users should know what to expect. > > BTW. Looking at the users commenting above - this is far too > aggressive for them and I agree it is. > > J. > > > J. > > On Sat, May 21, 2022 at 8:20 PM Ash Berlin-Taylor <[email protected]> wrote: > > > > https://github.com/semver/semver/blob/master/semver.md. > > > > Nothing says when you have to make breeding changes of course. > > > > But it's a sign to the users that something has broken. If you want to > wait six months feel free. But I don't think that should be our policy. I > the policy to be "we release under SemVer so can delete code that was > deprecated under the previous major version". No time requirement. > > > > On 21 May 2022 19:12:32 BST, Jarek Potiuk <[email protected]> wrote: > >>> > >>> Will min Airflow version aside: we agreed we're going to follow > SemVer, so I say we stick to that. X+1.0.0 (when ever we choose to release > it) is when we remove the deprecated code. > >> > >> > >> That's not entirely correct. Unfortunately semver.org is down now so I > >> cannot check my authoritative source :). But - from what I know, > >> SemVer does not really mandate removal of deprecations. > >> It says that (from memory) MAJOR version MAY contain breaking > >> changes, but it never (unless I am mistaken) states that you MUST make > >> braking changes for all deprecations. >
