potiuk opened a new pull request, #71040: URL: https://github.com/apache/airflow/pull/71040
The constraints published with a version were whatever the `constraints-X-Y` branch happened to hold when the release ran — a resolution made by the last CI build, for the sources at that moment, rather than for the version being released. The candidate tagged that tip and the final release retagged the candidate, so no release ever resolved constraints of its own. ### What happens now The stage is derived from the version, so it cannot be set inconsistently with it: | Version | Pre-releases | Lands on | Tagged | |---|---|---|---| | `3.1.3rc1` | allowed | `constraints-3.1.3rc1`, branched off `constraints-3-1` | `constraints-3.1.3rc1` | | `3.1.3` | refused | `constraints-3-1` (commit) | `constraints-3.1.3` | A candidate resolves **allowing pre-releases**: the providers of the wave being voted on exist on PyPI only as `rcN` versions, so constraints that refuse pre-releases cannot describe what a tester is asked to install. It lands on a branch of its own, leaving the branch every other build reads where it was. A final **cannot promote those by retagging** — a released version must never pin an rc — so it resolves the same set again without pre-releases, against the providers now published as finals, and commits onto `constraints-X-Y`. That commit is what makes the released constraints the baseline everything downstream reads, which also removes the need to refresh the branch beforehand. ### How it runs A new `release-constraints.yml` workflow, so the work happens on CI runners rather than on the release manager's machine, which would otherwise need a CI image for every supported Python before it could cut a release. `start-release` and the RC command trigger it; it is also reachable on its own for redoing a candidate's constraints or producing them for a release cut before this existed: ``` breeze workflow-run release-constraints --version 3.1.3rc1 --ref v3-1-stable ``` Only the PyPI constraints are regenerated — the other modes serve CI, and moving them here would change them for reasons unrelated to the release. ### Notes for reviewers - `--allow-pre-releases` is threaded through `generate-constraints` to `--pre` on the uv resolve, matching the convention already in `install_airflow_and_providers.py`. - The reusable workflow's new input deliberately does **not** use `ALLOW_PRE_RELEASES` as its env var name — that is the breeze option's own envvar, and having both set it would obscure which is in force. - `get_constraints_branch_for_version` and its test are removed: the workflow derives the branch now, so it was dead. - Untested end-to-end — the workflow cannot be dispatched until it is on `main`, so the candidate path in particular is unexercised. --- ##### 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]
