> > It just means that ANY major release can remove deprecated code regardless > of when we introduced the deprecation.
Precisely, yes. On Sat, 21 May 2022 at 20:23, Elad Kalif <[email protected]> wrote: > 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. >>> >>
