Hey all, The proposal I got has been merged (got a "let's see how it works") approval for Ash. but I think it's worth retroactively calling for a lazy consensus on that one (we can always revert it as this is doc-only change).
I do believe it will have no strong effects - let's see how it works. We can always revisit it in the future. I will also shortly work on some guidelines for poetry and pipenv users on how they can utilise our constraints in their workflows to not exclude those users from "constraint" mechanisms. Unless someone strongly objects - in 72 hrs (Fri 18th 11 CET) we will keep the approach there. Here are details: https://github.com/apache/airflow/blob/main/README.md#approach-to-dependencies-of-airflow In short (for the airflow core) it boils down to: Whenever we upper-bound such a dependency, we should always comment why we are doing it - i.e. we should have a good reason why dependency is upper-bound. And we should also mention what is the condition to remove the binding. And we have a few dependencies that we upper-bind by default: * SQLAlchemy: upper-bound to specific MINOR version (SQLAlchemy is known to remove deprecations and introduce breaking changes especially that support for different Databases varies and changes at various speed (example: SQLAlchemy 1.4 broke MSSQL integration for Airflow) * Alembic: it is important to handle our migrations in predictable and performant way. It is developed together with SQLAlchemy. Our experience with Alembic is that it very stable in MINOR version * Flask: We are using Flask as the back-bone of our web UI and API. We know major version of Flask are very likely to introduce breaking changes across those so limiting it to MAJOR version makes sense * werkzeug: the library is known to cause problems in new versions. It is tightly coupled with Flask libraries, and we should update them together J.
