potiuk commented on issue #19328: URL: https://github.com/apache/airflow/issues/19328#issuecomment-959962812
> > > Provider facebook: 2.1.0rc1 > > > Provider google: 6.1.0rc1 > > > microsoft.azure 3.3.0rc1 Hey @mik-laj - thanks for raising your concenrs. i looked closer, and I do not see those changes as really "breaking" (or at least not really breaking enough and under our control to justify major version change (but I am open to hear to arguments if others disagree). ## Facebook Facebook API does not follow SemVer. AT ALL. They mostly introduce new features and bugfixes when they bump the version. More interestingly, they even CHANGE behaviour of old versions of APIs when this behaviour is working for quite some time in the new versions. Here are the changes to insights features we are using for example: > Insights > Applies to v9.0+. Will apply to all versions on May 9, 2021. > IG User follower_count values now align more closely with their corresponding values displayed in the Instagram app. In > addition, follower_count now returns a maximum of 30 days of data instead of 2 years. and: > Ads Insights API > Updated date_preset parameter > Applies to v10.0+. > The lifetime parameter (date_preset=lifetime) is disabled and replaced with date_preset=maximum, which can be used to retrieve a maximum of 37 months of data. The API will return an error when requests contain date ranges beyond the 37-month window. > For v9.0 and lower, there will be no change in functionality until May 25, 2021. At that time, date_preset=maximum will be enabled and any lifetime calls will default to maximum and return only 37 months of data. and: > Deprecation of Store Visit Metrics > Applies to 11.0+. Will apply to all versions on Sept. 6, 2021. This means that the version 6.0 of "insights" we were using so far has anyway changed behaviour on Sep 6th this year to match the current 11+ behaviour :scream: So from what we see here, Facebook has chosen a "move fast break things" approach for their APIs. I assume Facebook users know it and I think the approach we took is a good one - we should not really try to keep compatibilty with version vN of Facebook, because even they don't do/recommend it (and we won't be able to actually do that because they can anyhow change the behaviour without us knowing it). So keeping the approach where by default API version is "latest" seems like a good approach and I do not see it really breaking anything. ## Cosmos > Provider microsoft.azure: 3.3.0rc1 > update azure cosmos to latest version (#18695): @eladkal I looked at the changes again, and I do not see any breaking change. We indeed sometimes (but not always) bumped major versions for our providers when underlying libraries changed but only when they changed the Airflow API of that provider (format of data returned and similar). The sheer fact of library upgrading it's version does not automatically invalidates and forces bump to new version of all the applications and libraries using it. In this particular case, we simply adapted our implementation so that the API remained the same (the breaking change which affected us was simply throwing a different exception - in our case we caught it and returned None, and this behaviour remained so there is no reason to bump the major version here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
