> - a deprecation could be announced in providers' version X, should not be > removed in X+1 version and deprecation could be removed in X+2 version > assuming "deprecation notice period" passes.
This is no longer SemVer then. On 21 May 2022 15:52:12 BST, Rafal Biegacz <[email protected]> wrote: >Elad - thank you for bringing this topic! > >In general, it seems that we have two big groups of users: >a) those who are on top of all the changes in Airflow and Airflow Providers >- these users are eager to change their DAGs to adjust to newer versions >quickly. >b) users who want to implement some DAGs and they want to run them for as >long as it is possible (it's especially true in case of Enterprise users) > >One consequence of very short deprecation notice periods will be that users >will be less eager to upgrade to newer versions of providers. >On the other hand, users are recommended to use up-to-date/maintained >providers - which is good for them. > >I'm inclining towards: > > - 3 or 6-month deprecation notice periods (I'm evenly split between > these two options); definitely, it should not be shorter than 3 months. > - a deprecation could be announced in providers' version X, should not > be removed in X+1 version and deprecation could be removed in X+2 version > assuming "deprecation notice period" passes. > >Regards, Rafal. > >PS. Deprecations also introduce challenges with delivering fixes and >maintaining of already released versions. > In the case of Google providers 6.8.0 we had a challenge with two >items: problem with CloudSQL Proxy Runner and lack of support for Google >Ads API v10. > > - Both items were fixed in providers 7.0.0 but the fixes were coming > with a price - several deprecated Google operators and operator parameters > were removed so to get the fixes users would need to modify lots of their > other DAGs > - In case of Composer, we ended up with producing custom version of > Google providers - built based on 6.8 with required fixes. > IMHO, we should produce a community version of Google providers 6.8.1 or > 6.9 to fix it. > > > >On Sat, May 21, 2022 at 1:33 AM Kaxil Naik <[email protected]> wrote: > >> 6 months and even 3 months sounds too long for releasing a major version >> of provider to be honest. Providers follow strict sem-ver, effort to >> downgrade to previous version is very less compared to core Airflow. >> Similarly effort to upgrade is less too. >> >> So I would vote for a guideline for deprecation for 2 releases with an >> exception where it is not possible to provide a deprecation before breaking >> change path. >> >> Regards, >> Kaxil >> >> On Fri, 20 May 2022 at 23:03, Ash Berlin-Taylor <[email protected]> wrote: >> >>> My vote is for remove it as soon after the major ver of the provider is >>> released, or as soon as anyone remembers anyway :) >>> >>> On Fri, May 20 2022 at 22:58:54 +0300, Elad Kalif <[email protected]> >>> wrote: >>> >>> Providers follow semver just like airflow core. >>> >>> If you upgrade to a major release it means that there are breaking >>> changes and you should read the release notes to know what they are. >>> Breaking changes can happen regardless of removing deprecated features. >>> >>> Google provider for example had several breaking changes releases (2.0.0, >>> 3.0.0 etc..) only in 7.0.0 we removed deprecated features. >>> >>> >>> >>> בתאריך יום ו׳, 20 במאי 2022, 22:50, מאת Mateusz Henc >>> <[email protected]>: >>> >>>> Hello, >>>> Right, nobody forces you to upgrade, but sometimes you wait for an >>>> important bug fix/new feature that is coming in the new version and you are >>>> surprised by the breaking change there. >>>> >>>> Isn't the problem with deprecations more about their visibility? How can >>>> users learn today that they use a deprecated feature? I think it's only >>>> from logs. >>>> But if dags are running fine, there is no need to check logs. >>>> >>>> Shouldn't information about new deprecations be included in release >>>> notes for the package? >>>> >>>> Best regards, >>>> Mateusz Henc >>>> >>>> >>>> On Fri, May 20, 2022 at 5:39 PM Daniel Standish >>>> <[email protected]> wrote: >>>> >>>>> > It means, in a 3 months period, a developer needs to [do lots of >>>>> things...] >>>>> >>>>> When removal is released (say after a min of 3 months since >>>>> deprecation), as a user nothing forces you to upgrade to the latest major >>>>> *immediately*. >>>>> >>>>>
