Both have nothing to do with Providers. -> Both have nothing to do with Core.
On Sat, May 21, 2022 at 6:48 PM Ash Berlin-Taylor <[email protected]> wrote: > > > - 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. >>>>>>
