Skip to content

Retention: start prerelease_superseded_for_days at the later of release and prerelease publication - #842

Open
schmitch wants to merge 2 commits into
mainfrom
claude/757-prerelease-superseded-clock
Open

schmitch wants to merge 2 commits into
mainfrom
claude/757-prerelease-superseded-clock

Conversation

@schmitch

@schmitch schmitch commented Nov 3, 2026 •

Copy link
Copy Markdown
Member

Fixes #757

Problem

prerelease_superseded_for_days counted only from the superseding release's publication. If a prerelease was published after that release (a lagging CI version bump such as 2.3.0-ci.500 a month after 2.3.0, or a maintenance line's 1.9.1-rc.1 after 2.0.0), the next run hard-deleted it, sometimes minutes after it was published.

Change

  • crates/core/src/retention/evaluate.rs: in triggers_match, the clock now starts at max(release.created_at, prerelease.created_at), so a prerelease always gets its N days. The module docs say the same. Which release supersedes a prerelease (superseding_releases, superseded_by) is unchanged.
  • docs/retention.md: the criteria table now gives the new starting point.
  • docs/changes/2.2.0/757.fixed.md: changelog fragment.

Tests

  • New unit test a_prerelease_published_after_its_release_has_its_days_too. It covers prereleases published before and after 2.3.0, plus a maintenance-line rc, at both 14 and 25 days.
  • crates/core/tests/retention_worker.rs::unlisted_and_superseded_versions_go_after_their_days now also seeds 2.0.0-ci.2, published 2 days ago, after 2.0.0. It is kept.
  • crates/server/tests/admin_retention.rs::preview_shows_the_new_triggers_decisions_and_the_next_runs: its comment said the CI builds come before 1.0.0, but the fixture left them at now(), which is after the release. Under the old behaviour they were deleted anyway. With this fix they keep their 14 days, so the test now backdates them 30 days to match its comment. No assertion changed.
  • Both new checks fail without the fix and pass with it.
  • cargo test -p forge-core --lib retention: 115 passed. cargo test -p forge-core --test retention_worker: 22 passed. cargo test -p forge-server --test admin_retention: 17 passed.
  • cargo clippy -p forge-core --all-targets -- -D warnings, cargo clippy -p forge-server --tests -- -D warnings, cargo fmt --all --check and cargo xtask changelog --check all pass.

No admin API or web UI change.

🤖 Generated with Claude Code

https://claude.ai/code/session_012e6DJbobLATLgHyeaU5Gqa

…ation

prerelease_superseded_for_days started its clock at the superseding
release's publication only, so a prerelease published after its release
(a lagging CI version bump, a maintenance line's rc after a newer major)
was hard-deleted on the next run. The clock now starts at
max(release.created_at, prerelease.created_at): a prerelease always has
its N days. docs/retention.md says so; a unit test and the worker test
cover a prerelease published after its release.

Fixes #757

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012e6DJbobLATLgHyeaU5Gqa
The preview test meant its CI builds to come before 1.0.0, but it left
them at now(), after the release. Since #757 such a build keeps its 14
days, so the test now backdates them as its comment says.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012e6DJbobLATLgHyeaU5Gqa

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Retention: prerelease_superseded_for_days deletes a prerelease published after its superseding release on the next run

2 participants