potiuk commented on code in PR #26109: URL: https://github.com/apache/airflow/pull/26109#discussion_r962015482
########## airflow/providers/presto/provider.yaml: ########## @@ -38,7 +39,7 @@ versions: dependencies: - apache-airflow>=2.2.0 - - apache-airflow-providers-common-sql>=1.2.0 + - apache-airflow-providers-common-sql>=1.1.1 Review Comment: > I disagree -- for anything but postgres provider the update is essentially noise. We're making users think about updating/work out what has changed , but odds are the update would have no effect on most of them I think it makes no impact on users - they will just bump the common.sql provider automatically without even knowing about that (that's the power of requirements), it's largely invisible for the users, because users will never upgrade the common.sql on their own and we should do it for them. My view on the "common" providers (and similarly for any other common functionality we might add - we already discussed taskflow for comon taksflow functions) is that this is the way to enable new "common" code without bumping Airflow version, and without incurirng the current penalty on backwards compatibilityl The problem if we DON't bump the common version is that we have no way to test it easily. We are not able to test if the new postgres provider does not use any of the 1.2 features implicitly or by accident. So updating the common.sql to >=1.2.0 is our own sanity to not having to run tests of the new provider versionn with 1.1.0 and 1.0.0 Are you sure that the new postgres provider is goign to work with common.sql 1.0.0 and 1.1.0 ? I am not . How are you going to test it if someone adds new code to postgres provider? We currently have no way of testin it. We could add more test matrix but I think it makes little sense. I treat common.sql as a playground to test and see what kind of problems it might introduce and this is the result of observing similar issue. That's why I think with the common providers, pretty much always we: * not have backwards incompatible changes 1.* version for as long as we can * add >=1.N.0 every time we release 1..N.0 for all providers that depend on them Do you think there are other ways we can make sure 1.0.0 and 1..1..0 common.sql compatibility can be tested in the nest release? -- 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]
