potiuk commented on PR #24454: URL: https://github.com/apache/airflow/pull/24454#issuecomment-1155774282
> What is the effort in creating: > Constraint-2.3.2-latest? 1st of all this is not for installing latest providers on "latest" airflow, but installing them on ANY compatible airflow. For this last scenario we are rather limited in what we can do. The overhead is not that big for just "latest" airflow - we are actually doing it every time when we release a bugfix release already - so 2.3.3 constraints are exactly that when we prepare them. The question is - if we start adding constraints for "previous" releases of Airflow - should we do it for "latest" stable release only, or for "all versions". Which versions? I think it's a no-go for anything but the latest release due to overhead "per version" it needs. And to be honest - it does not help a lot to anyone but those who are on the latest version of it is the "latest" only. Plus it is not always possible, we would have to likely manually remove some providers - `pip` resolution is not perfect, as it might get to bactracking cycles, and I am afraid if we "commit" to releasing such constraints, we are going to have a lot of work to solve those. And in some cases (like k8s provider with conflicting kubernets library update) it won't be possible at all. And it's not really problematic actually. we have roughly 1.5- monthly release cycle for Airlfow bugfixes. So we are usually talking about max 2 weeks gap between those two events. And it will automatically use the latest providers, so I'd rather encourage people to update to latest bugfix release. Another possibility (hinted in the survey) - maybe even better we could also adapt our release schedule for providers - it does not have to be "exactly monthly" - even now it is "roughly monthly". So we could make sure we release all providers a week (or 1.5 week) before a new bugfix/feature release of Airlfow - making sure that when we release the "latest" it always has "just released" providers as well. That might actually be the easiest and best way to do. -- 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]
