Pin providers in constraints to the versions published in PyPI

[potiuk]

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.

Minimum versions added for five unbounded dependencies

The lowest-direct-resolution test suite ("Low dep tests") resolves direct dependencies to the oldest version their specifier permits. A dependency with no lower bound therefore drops all the way to its first-ever release, which for a compiled package means building a decade-old sdist against a current toolchain:

warning: The direct dependency `krb5` is unpinned. Consider setting a lower bound when using
         `--resolution lowest` or `--resolution lowest-direct` to avoid using outdated versions.
   Building krb5==0.3.0
 × Failed to build `krb5==0.3.0`

uv warns about exactly this. Each of these now carries the floor it is actually developed and tested against:

Distribution	Dependency	Floor
providers/samba (kerberos extra)	krb5	>=0.8.0
providers/akeyless (cloud_id extra)	akeyless-cloud-id	>=0.3.0
providers/apache/spark (dev group)	pyspark	>=4.0.0
providers/common/ai (dev group)	pydantic-ai-slim[mcp]	>=2.0.0
dev/registry (dev group)	pytest	>=9.1.1

The akeyless requirement is also spelled with the normalised distribution name (akeyless-cloud-id rather than akeyless_cloud_id). The two extras are user-facing, so the provider docs tables were regenerated to match.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker f9b72d8 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.