potiuk opened a new pull request, #71081:
URL: https://github.com/apache/airflow/pull/71081
…g whatever exists (#71040)
* Resolve the constraints a release ships instead of tagging whatever exists
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.
A candidate now resolves them allowing pre-releases: the providers of the
wave being voted on exist on PyPI only as rc versions, so constraints that
refuse pre-releases cannot describe what a tester is asked to install. They
land on a branch of the candidate's own, leaving the branch every other build
reads where it was. The final release cannot promote those by retagging - a
released version must never pin an rc - so it resolves the same set again,
without pre-releases, and commits onto constraints-X-Y, which is what makes the
released constraints the baseline everything downstream reads.
Which of the two happens is derived from the version, so the stage cannot be
set inconsistently with it. The work runs 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, and is reachable on its own
through `breeze workflow-run release-constraints` for redoing a candidate's
constraints or producing them for a release cut before this existed.
* Let only the providers answer with a pre-release
`--pre` applies to the whole resolution, so a candidate's constraints could
pin a pre-release of any dependency - a beta of some third-party library would
end up in what a release ships, which is not what allowing rc providers was
meant to permit. uv considers a pre-release for a package only when a
requirement for it mentions one, so naming the providers with a pre-release
lower bound confines the allowance to them and leaves every other package on
the default policy.
* State the pre-release scoping rather than leaning on uv's default
The rc lower bounds already confined pre-releases to the providers, but only
because uv's default strategy happens to permit them for explicitly marked
packages. Naming `explicit` says that in the command instead of leaving it to a
default that could change, and drops the `if-necessary` half of that default -
the part that would let a package nobody marked resolve to a pre-release when
no final version satisfies it.
* Document what a release manager now sees at the constraints step
The candidate half was undocumented - the release notes described only what
the final release does, leaving a release manager to infer why a candidate
suddenly grows a branch and a tag of its own, and why its constraints pin rc
providers when nothing else in them is a pre-release. Both stages and the scope
of the pre-release allowance are stated where each is reached.
* Register the new constraints command where the docs checks look for it
A command has to be grouped in its `*_commands_config.py` and embedded in
one of the breeze docs, or the static checks reject it - `--allow-pre-releases`
had no group and `workflow-run release-constraints` had a generated screenshot
that nothing referenced. The two `setup` screenshots move because the command
list they render is exactly what gained the new entry.
(cherry picked from commit 26d53bd1e84088bf7cb7ab11dcfde3d8e6b99048)
<!-- SPDX-License-Identifier: Apache-2.0
https://www.apache.org/licenses/LICENSE-2.0 -->
<!--
Thank you for contributing!
Please provide above a brief description of the changes made in this pull
request.
Write a good git commit message following this guide:
https://chris.beams.io/posts/git-commit/
Please make sure that your code changes are covered with tests.
And in case of new features or big changes remember to adjust the
documentation.
For user-facing UI changes, please attach before/after screenshots (or a
short
screen recording) so reviewers can assess the visual impact.
Feel free to ping (in general) for the review if you do not see reaction for
a few days
(72 Hours is the minimum reaction time you can expect from volunteers) - we
sometimes miss notifications.
In case of an existing issue, reference it using one of the following:
* closes: #ISSUE
* related: #ISSUE
-->
---
##### Was generative AI tooling used to co-author this PR?
<!--
If generative AI tooling has been used in the process of authoring this PR,
please
change below checkbox to `[X]` followed by the name of the tool, uncomment
the "Generated-by".
-->
- [ ] Yes (please specify the tool below)
<!--
Generated-by: [Tool Name] following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
-->
---
* Read the **[Pull Request
Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)**
for more information. Note: commit author/co-author name and email in commits
become permanently public when merged.
* For fundamental code changes, an Airflow Improvement Proposal
([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals))
is needed.
* When adding dependency, check compliance with the [ASF 3rd Party License
Policy](https://www.apache.org/legal/resolved.html#category-x).
* For significant user-facing changes create newsfragment:
`{pr_number}.significant.rst`, in
[airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments).
You can add this file in a follow-up commit after the PR is created so you
know the PR number.
--
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]
