potiuk opened a new pull request, #71324: URL: https://github.com/apache/airflow/pull/71324
Constraints cut for a release candidate have to land on the wave being voted on, whose providers exist in PyPI only as rc versions. Asking `uv` for a pre-release strategy (`--prerelease explicit` plus a `>=0.0.0rc0` lower bound per provider) left it free to answer with any version satisfying those bounds, so the pins were neither the candidate nor the last release. Now the versions are retrieved from PyPI and named, so there is nothing left to resolve — the constraints pin what is actually published: * every active provider is pinned with `==<version>` at the newest version PyPI can actually install for the Python being resolved (fully yanked releases, releases with no files, and releases excluded by `requires_python` are passed over); * a pre-release is only ever considered when `--allow-pre-releases` is set, and even then it has to sort above every final release — so a provider without a candidate in the wave keeps its release, and a released constraints file can never carry an rc pin; * a provider PyPI does not have yet (first release still in the wave) is left unpinned, so a locally built wheel can still answer for it; * `--prerelease explicit` and the `>=0.0.0rc0` bounds are gone. Checked against live PyPI while the current wave is being voted on: ``` google: final=22.2.2 with pre-releases=22.3.0rc4 cncf-kubernetes: final=10.20.0 with pre-releases=10.21.0rc3 amazon: final=9.34.0 with pre-releases=9.34.0 ``` A release candidate is also exempt from the provider downgrade check: it pins the wave being voted on, which sorts below the releases the constraints branch already carries, so the comparison says nothing there. The check still runs for finals, where it now catches the pinned version disappearing (yanked, or no longer offering a file for that Python). Finally, re-running `release-constraints.yml` for the same candidate now deletes and re-creates that candidate's branch and tag instead of pushing onto them — otherwise the second run hits a non-fast-forward push and a tag that already exists. Finals are untouched: they still commit onto the shared `constraints-X-Y`. One consequence worth calling out: with `==` pins on the regular run too, two providers whose newest releases need incompatible dependencies now fail generation outright instead of quietly settling on an older provider and tripping the downgrade check. The install-failure message says so and points at the `additional_constraints_for_highest_resolution` escape hatch. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- 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]
