> `apache-airflow-providers-common-compat>=1.7.4 # TODO: bump` > > to use the math expression and use this as marker like: > > `apache-airflow-providers-common-compat>1.7.4` <-- greater not greater > or equal > > Not sure whether this makes "new" problems in dev-env as breeze locally > might fail as >1.7.4 is just not existing or will it still use it from > repo/main? Just tesintg it with a small change on main generates an > error with: apache-airflow-providers-standard 1.9.0 has requirement > apache-airflow-providers-common-compat>1.7.4, but you have > apache-airflow-providers-common-compat 1.7.4 >
That's precisely the issue. It's really another manifestation of "chicken-egg" problem that we had been trying to solve for quite some time in various ways (we even had "chicken-egg-providers" option in the CI and breeze for a while - I am actually resurrecting that a bit in my 2.11.1 / Fab 1.5.4 PR where breeze is "old" and struggling a bit with it in https://github.com/apache/airflow/pull/51681... Back then the problem was that we had "new" versions of providers in development, and "old" versions in PyPI so things get nasty in the release branch where we use PyPI release provider - but this problem is already fully automated and transparently resolved in our code (and removal of .dev0 suffix was a crucial part in it). The issue there is really logical disconnect between "dev" dependencies and "release" dependencies. When we want to test things in main -> we want all the versions of providers be installable together - which means that the <, > deps have to be "non-conflicting" - but then - we only truly know what will be the next version of provider at the moment of release. And also there are RC versions and time of voting when we already **must** have new versions in main but the new versions are not yet released in PyPI (and funny things happen when we also want to release and test airflow release while voting for providers is in progress, and ... it will get even more complex when - as we discuss - we might have several provider "batches" in parallel being voted 😱😱😱😱😱 So we need to have some convention here that: a) works when you do uv sync and allow to install those providers together b) but allows to change and update release versions by RM at the moment of release c) works in different stages - pre-release, during voting, after release The > or >= does not change much, it's really the "uncertainty" of what will be released as the new provider version is the issue. Plus of course making it obvious what to do for contributors, and not to miss something when you are release manager. With all that combined, I have a feeling that "signaling to RM what to do" should be on the contributor's side, and "doing" should be on the RM side - this makes it clear what are the responsibilities on both sides. I think the only question is what "convention" to use. There is no "standard" we could follow, the # TODO seems to be really low-barrier and easy to grasp by contributors and automated to avoid mistakes by RM. This is my line of thought at least. But any more comments and suggestions are most welcome :). J,
