rethinking about this I do support Ash's approach. > Following the above. Are you proposing we make it as a rule?
The rule is that we can. It doesn't mean that we will every time. It just means that ANY major release can remove deprecated code regardless of when we introduced the deprecation. The community is welcome to express their opinions on specific cases - everything is transparent. > If users were caught by surprise with breaking changes in major versions, then maybe the other major versions we released were "not breaking". The surprise I'm referring to is that this is the first time we actually removed deprecated features in providers. When I removed deprecated features for Google 7.0.0 release I didn't expect it to be a surprise. I only learned it after the release which is why I started this thread. On Sat, May 21, 2022 at 10:04 PM Kaxil Naik <[email protected]> wrote: > 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. >> >
