Skip to content

Skip yanked newer versions in constraints-version-check#65236

Merged
eladkal merged 1 commit intoapache:mainfrom
potiuk:constraints-version-check-skip-yanked
Apr 14, 2026
Merged

Skip yanked newer versions in constraints-version-check#65236
eladkal merged 1 commit intoapache:mainfrom
potiuk:constraints-version-check-skip-yanked

Conversation

@potiuk
Copy link
Copy Markdown
Member

@potiuk potiuk commented Apr 14, 2026

A yanked release must never be proposed as an upgrade candidate by breeze release-management constraints-version-check. This change treats a release as "does not exist" when PyPI reports that all of its files are yanked, so yanked versions are ignored when:

  • picking the latest version (with or without cooldown),
  • counting how many versions the constraints file is behind,
  • finding the first newer release date, and
  • deciding whether any newer release has appeared since the constraints file was generated (in diff-constraints mode).

The pinned version itself is never filtered — only versions being evaluated as "newer than current".


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 4.6)

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

…rent

When a newer release has been yanked from PyPI it must not be proposed as
an upgrade candidate. The check now treats a release as "does not exist"
when all of its files are yanked, so yanked versions are ignored when
picking the latest version (with or without cooldown), counting versions
behind, and determining whether a package has any newer release since
the constraints file was generated.
@eladkal eladkal merged commit d1d313a into apache:main Apr 14, 2026
141 checks passed
@github-actions
Copy link
Copy Markdown
Contributor

Backport failed to create: v3-2-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-2-test Commit Link

You can attempt to backport this manually by running:

cherry_picker d1d313a v3-2-test

This should apply the commit to the v3-2-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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:dev-tools backport-to-v3-2-test Mark PR with this label to backport to v3-2-test branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants