Renovate: Feature Request: Option to always stay X weeks out of date

[adrw]

What would you like Renovate to be able to do?
I don't want my repo on the very bleeding edge but only to consider bumps for packages that are >4 weeks old and thus have any bugs/kinks worked out in the event of a bad release.

Describe the solution you'd like
A way to configure the acceptable delay delta of considered bumps.

Describe alternatives you've considered
Can't find a way to do this currently other than manually evaluating bumps.

[rarkins]

I think this is a good idea but never worked out a fool-proof approach. If v1.1.0 was 4 weeks old but v1.1.1 was 3 weeks and 6 days old, would you want a PR for v1.1.0 even though we can logically assume that v1.1.1 probably fixed a problem with v1.1.0? If so then you may end up with the opposite of what you were hoping - you've deployed a buggy/bad version.

If instead we changed the rule to say "only update when latest release is 4 weeks old" then if you get any project that releases more often then monthly then you'd never get a release.

I've also considered if we can use different "stability" periods depending on release type. e.g. for a major release, I might also think 4 weeks. For a minor release, maybe 1-2 weeks, and for a patch release maybe also 1 week. e.g. if a patch is released and no newer patch or release is out within a week, we can assume some level of stability.

FYI we're also working on the ability to communicate to you a confidence factor we have in releases, and that will be partly based on (a) aggregate test passes (all users) and (b) what % of users have already upgraded to a release. I think that the % upgrade is a good signal about the safeness of a release, assuming we observe no rollbacks.

[adrw]

@rarkins Wow! Thanks for the thorough response, glad that it's been on your radar and been given a lot of thought. The confidence factor sounds like a good approach and we'd be eager to try that in our repos once it's ready for testing.

[joonastanner]

Hi @rarkins - my company is also very interested in this feature! We realized this with the recent eslint v6 upgrade, as Renovate Pro generated a large number of PRs for that in our repos, but we found out we actually cannot make the upgrade just yet, because we will need to wait for community modules like eslint-loader to get updated to support the new version first. So it generates a lot of noise for us.

I also like the idea if we can delay for a few weeks after any major version, as most of the time there will be noise and wasted time from trying to jump to a new major version too soon. Alternatively, if we could set that we only get PRs after version x.0.1 or x.0.2 or even x.1.0 has been released, it could work, as we can usually expect the biggest issues with any new major version to have been ironed out by that point. And a better chance for community modules to already support the new version by that time as well.

[rarkins]

FYI this is one of my highest priorities to address soon.

[renovate-bot]

:tada: This issue has been resolved in version 19.34.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[rarkins]

https://renovatebot.com/docs/configuration-options/#stabilitydays

[worldtiki]

Sorry for commenting on an old thread but, for Maven dependencies, where is the release timestamp sourced from?
The docs are not very clear. I've been getting a few PRs open almost immediately after a new version is available and I'm not quite sure how to fix this.

[rarkins]

There may not be a timestamp retrieves. Best if you raise a new issue