Skip to content

Shift constraints-version-check coloring by --cooldown-days#65233

Merged
potiuk merged 1 commit into
apache:mainfrom
potiuk:constraints-version-check-cooldown-coloring
Apr 14, 2026
Merged

Shift constraints-version-check coloring by --cooldown-days#65233
potiuk merged 1 commit into
apache:mainfrom
potiuk:constraints-version-check-cooldown-coloring

Conversation

@potiuk

@potiuk potiuk commented Apr 14, 2026

Copy link
Copy Markdown
Member

Shifts the staleness thresholds used by breeze release-management constraints-version-check by --cooldown-days, so that time a package spent in the cooldown window (during which it is intentionally ignored by the check) no longer counts against its staleness.

Previously, a release that had just cleared the cooldown could flip straight from "not considered" to "🔶 warning" on the next run, because the 5d/30d thresholds were absolute. With this change the thresholds become 5 + cooldown_days and 30 + cooldown_days, so a package that just became eligible is still reported as "📢 new". The row status labels and the footer summary reflect the shifted thresholds as well.

No behavior change when --cooldown-days=0.


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

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
@potiuk potiuk merged commit 0e0aaed into apache:main Apr 14, 2026
37 checks passed
@potiuk potiuk deleted the constraints-version-check-cooldown-coloring branch April 14, 2026 17:01
@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 0e0aaed 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.

potiuk added a commit to potiuk/airflow that referenced this pull request Apr 14, 2026
…ooldown-days (apache#65233)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
potiuk added a commit that referenced this pull request Apr 14, 2026
…ooldown-days (#65233) (#65252)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)
vatsrahul1001 pushed a commit that referenced this pull request Apr 15, 2026
…ooldown-days (#65233) (#65252)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)
vatsrahul1001 pushed a commit that referenced this pull request Apr 15, 2026
…ooldown-days (#65233) (#65252)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)
vatsrahul1001 pushed a commit that referenced this pull request Apr 15, 2026
…ooldown-days (#65233) (#65252)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)
vatsrahul1001 pushed a commit that referenced this pull request Apr 15, 2026
…ooldown-days (#65233) (#65252)

Package time spent inside the cooldown window no longer counts against
staleness, so a release that just cleared the cooldown is still reported
as "new" instead of flipping to "warning" immediately. The shifted
thresholds are reflected in the row status labels and footer summary.
(cherry picked from commit 0e0aaed)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants