Feature Request
Since this repo uses Renovate, could we enable a dependency cooldown (minimum “release age”) so Renovate won’t propose updates to dependency versions until they’ve been out for a bit?
Example policy: only update to releases that are at least 7 days old (optionally 14 days).
Why – security motivation
A large fraction of OSS supply chain compromises have a short “window of opportunity” (hours to days) between a malicious release being published and being detected/reported/taken down.
If we auto-upgrade immediately, we maximize exposure during that window. A cooldown is a simple mitigation: wait out the noisy period so that compromised releases are more likely to be flagged/removed before we adopt them.
Reference/motivation: “We should all be using dependency cooldowns” (Nov 21, 2025).
Proposal
Enable Renovate’s minimum release age policy, e.g.:
- Default:
minimumReleaseAge: 7 days
- Optional stricter:
minimumReleaseAge: 14 days (at least for higher-risk surfaces like build tooling / GitHub Actions)
Feature Request
Since this repo uses Renovate, could we enable a dependency cooldown (minimum “release age”) so Renovate won’t propose updates to dependency versions until they’ve been out for a bit?
Example policy: only update to releases that are at least 7 days old (optionally 14 days).
Why – security motivation
A large fraction of OSS supply chain compromises have a short “window of opportunity” (hours to days) between a malicious release being published and being detected/reported/taken down.
If we auto-upgrade immediately, we maximize exposure during that window. A cooldown is a simple mitigation: wait out the noisy period so that compromised releases are more likely to be flagged/removed before we adopt them.
Reference/motivation: “We should all be using dependency cooldowns” (Nov 21, 2025).
Proposal
Enable Renovate’s minimum release age policy, e.g.:
minimumReleaseAge: 7 daysminimumReleaseAge: 14 days(at least for higher-risk surfaces like build tooling / GitHub Actions)