Configuring release cool-off period (no releases for x time-duration)

[kachkaev]

Extracted from #30527 (reply in thread)

---

I'm looking for "no releases for x time-duration" option. It could be used alongside or instead of minimumReleaseAge. The use case is exactly as described by @bzakdd in #30527.

Here is a scenario I'd like to avoid:

1. Version X.Y.Z is released on day 1 (it contains a serious non-security bug).
2. Version X.Y.{Z+1} is released on day 2 (the bug is fixed).
3. On day 4, Renovate sees version X.Y.Z as "more than three days old", creates a PR and merges it.
4. The project ends up using a buggy dependency until X.Y.{Z+1} is old enough to be merged.

It'd be great to have a parameter that prevents these situations. If there are several consequent releases (only 1-2 days apart), Renovate could wait until the package has 'cooled off'. Of course, maintainers could mark X.Y.Z as deprecated because of a serious bug but this happens quite rarely in practice.

In an ideal world, cool-off period option would only apply to automatically created PRs. As a user of Renovate Dashboard, I should be able to trigger an update with a cooled-off version as well as the very latest one. Just-released versions should not become 'invisible'.

[gaeljw]

Sounds to me the feature request is "do not suggest an upgrade if it's not the latest bugfix". Would that work?

[kachkaev]

It is something like that, yes. I'd say it's "Do not automatically merge an upgrade if minimumReleaseAge is reached but there is a newer non-major version available since then". Critical bugfixes are not necessarily made in X.Y.{Z+1}. It can be also X.{Y+1}.0 for example.

[LeSpocky]

4. _The project ends up using a buggy dependency until `X.Y.{Z+1}` is old enough to be merged._

This is exactly the scenario which popped up in my head after reading We should all be using dependency cooldowns and docs section Minimum Release Age afterwards. Thanks for raising this.

[kachkaev]

Here is a practical example. Prettier 3.7.0 was released recently and contained a critical non-security bug. It broke VSCode integration which was finally fixed in Prettier 3.7.3. Here is the timeline of Prettier releases:

https://github.com/prettier/prettier/releases/tag/3.7.0 - 2025-11-27T08:30:50Z
https://github.com/prettier/prettier/releases/tag/3.7.1 - 2025-11-27T11:32:54Z
https://github.com/prettier/prettier/releases/tag/3.7.2 - 2025-11-28T20:58:56Z
https://github.com/prettier/prettier/releases/tag/3.7.3 - 2025-11-29T17:55:30Z

I've got a project that lists prettier in devDependencies. My Renovate config automatically updates devDepenencies every weekend with minimumReleaseAge of 2 days. I just got a PR that bumps Prettier to 3.7.1, which happened one hour after 3.7.3 was released:

• Update dependency prettier to v3.7.1 kachkaev/website#926

By the time 3.7.3 reaches minimumReleaseAge, the weekend will be over so I'd be stuck with a broken 3.7.1 for a week. If Renovate had a notion of a 'cool-off period', 3.7.1 would be considered too 'hot' based on subsequent patches. A PR with a broken dependency would not be created.