potiuk commented on code in PR #46891:
URL: https://github.com/apache/airflow/pull/46891#discussion_r2203525936
##########
airflow-core/pyproject.toml:
##########
@@ -35,7 +35,7 @@ name = "apache-airflow-core"
description = "Core packages for Apache Airflow, schedule and API server"
readme = { file = "README.md", content-type = "text/markdown" }
license-files.globs = ["LICENSE", "3rd-party-licenses/*.txt", "NOTICE"]
-requires-python = ">=3.10,!=3.13"
+requires-python = ">=3.10"
Review Comment:
This is more of a result of recent discussion about upper-binding the python
version. I havve not yet fully settled on the strategy there but I think the
best description of it is:
* we should not upper-bind by default - because our software **might work**
with upcoming versions - we have no idea what incompatibilities it will have
until things are released. This is more for the future users of the software.
* unless we **know** our software is incompatible - then we should
explicitly exclude those released versions that we know are problematic -
especially if it helps with `uv sync` resolution of workspace. The problem is
that if we do not limit things that we **know** are problematic. For example
`uv sync` will fail if we do not upper-bind python versioin in those few cases
we know we should. This is more for maintainers and contributors.
So - i think we cannot have "consistent" and single approach. The best
description I have of the strategy is "Do not upper-bind things unless you know
you should".
--
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]
