potiuk commented on code in PR #27613: URL: https://github.com/apache/airflow/pull/27613#discussion_r1020103858
########## airflow/providers/alibaba/CHANGELOG.rst: ########## @@ -24,6 +24,20 @@ Changelog --------- +2.2.0 +..... + +Misc +~~~~ + +* ``Move min airflow version to 2.3.0 for all providers (#27196)`` Review Comment: Very good question. I was waiting for it :) I think it was a mistake to bump major version (But I can be convinced otherwise and change it). I think this is a perfect representation of the view I have on distinguishing the breaking from non-breaking change and Hyrum's Law - https://www.hyrumslaw.com/. Every change is technically breaking someone's workflow. Breaking change is not a "0/1" decision but a continuum and it's mainly up to us to decide how to classify it, based on likelihood it will break many user's workflows. The rationale i have - that from the point of view of provider, it's just a dependency change (which we generally consided non-breaking) and it does not break people's workflows in general at all. * If you are on Airflow 2.2, you cannot install this release anyway. So the change is not breking - from the point of view of Airflow 2.2 user, there is no change. The user will have to continue using old provider. * If you are on Airflow 2.3, you install it and it "just works". No breaking in your workflow whatsoever. There are two questions/potential problems/considerations here: 1) You could accidentally bring your airflow up if you have Airflow 2.2 and force installation of 2.3+provider. I'd argue it's a problem of the user and the most we can do it is to warn user about it in the documentation. This is also true for many of our dependencies. There are a number of dependencies that - when upgraded independently - might bring airlfow version up (for example sqlalchemy bump to 1.4 will upgrade airflow to 2.3). Unfortunately `pip` works like that and we cannot do anything about it - everything that happens there happens long before any of our code is executed and we cannot even give a warning to the user when the user attempts to do so. Here potentially the "major" bump might give the user a pause, but I argue that this is a very weak signal - the major bump should signal incompatibilities in the provider itself, not potential problems with Airflow. Luckily this is not destructive nowadays. User will get information about migrations not applied and will be able to recover. 2) I was thinking whether it shoudl be a "feature" or "patchlevel" bump. I chose "feature" pretty arbitrary here and without any good "reason". SemVer does not really address this case so we are free to choose whatever we feel is appropriate. And I think personally that signalling minor bump is a bit more prominent. We do not (I think) make it a breaking change (see above), but we also do not want to make it a "meh" change. We need to pick some scheme that will allow us to publish it as a new package in PyPI even without any changes. So I chose "feature". But it could be "patchlevel" as well. Both "patchlevel" and "feature" are not breaking (probably) user's workflow so choosing one over another is pretty arbitrary decision. I wonder what others think in this context. -- 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]
