I think it makes sense and I'm a +1. For the convenience of other readers I'll paste your rationale here:
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: > 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. > 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.
