bugraoz93 commented on code in PR #61634: URL: https://github.com/apache/airflow/pull/61634#discussion_r2784366218
########## .pre-commit-config.yaml: ########## @@ -16,7 +16,7 @@ # under the License. --- default_stages: [pre-commit, pre-push] -minimum_prek_version: '0.2.22' +minimum_prek_version: '0.3.2' Review Comment: Thanks for the comment! I tried to explain the reasoning here https://apache-airflow.slack.com/archives/C06K9Q5G2UA/p1770561908477689 Let me summarise here too, as I saw that the description of the PR is weak, Even small changes have an impact on the entire CI, so making changes step by step is also easier to review and inform the community well. Since static checks do not fail with the update, this is the most atomic part of the change. We regularly update packages/dependencies. There are certain packages/dependencies that we upgrade in intervals through automated detection, and with a semi-automated approach, we are upgrading those packages/dependencies. For these CI team and contributors, trying to keep everything green and adopting breaking changes or following those up. For example, `hooks` are also included in this process if there is no `# frozen: ...` comment on it. The contributors checking CI channel regularly and ensuring those are updated. There are some packages/dependencies we manually upgrade or min version like this that impacts entire community. There are not so many of them, but for those who generally find it hard to keep up with the updates daily or at more intervals, or we haven't updated them because new features are not needed. This PR is one of the changes that impact the community rather than keep things green with rebases. Hope it will enable us to use new features and try to provide one of the maintenance work at some point we need to do. **Why are we doing that?** For some, even minor upgrades cause a break in the CI or some part of the code, for example, due to an annotation change. Those are from the `uv` package manager to `prek` and even `fastapi` updates. **Why did I keep this PR atomic?** Normally, the upgrade PRs are generally merged within hours, and this one will have an impact on each developer in the community. This should be well communicated and people checking the PR shouldn't see lots of updates noises the actual change in this case. -- 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]
