potiuk commented on pull request #22005: URL: https://github.com/apache/airflow/pull/22005#issuecomment-1059801597
> I had many problems with the "latest version" in my projects > > If we are not fixing the version of `moto` then we should keep in mind that we can have failed tests for all PRs if let's say in version 3.1 something will be changed. This is what our constraint mechanism provides. All "regular" PRs if they do not change setup.py/setup.cfg use the constraints to run the PR - i.e. latest "good" version of dependencies. Only in `main` builds (after merge or on schedule) or in case someone modifies the setup.py/.cfg we run "eager upgrade" of all dependencies (and if the tests succeed, those become new constraints - they are automatically pushed to our repo). This way: 1) we have stable set of dependencies for regular constraints 2) we automatically upgrade the stable set with the newly released versions (with every merge and on nightly schedule) - and only when ALL tests succeed with them (this is great for security!). When we have no frequent flakes, we have 2-3 updates a day https://github.com/apache/airflow/commits/constraints-main (because we have 580 dependencies in total) 3) when there is a breaking release we detect it (as our main and "dependecy changing" PRs start failing) - and it gives us a chance to fix them without impacting regular PRs So - getting a failure in `main` when 3.1 is released with breaking change is GOOD and we are prepared to handle it - this will give us a chance to see it and fix it before most of the contributors even realise it happened. If want to see more - my talk about it from November: https://youtu.be/_SjMdQLP30s?t=2519 -- 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]
