Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
adrw opened this issue Jun 5, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@adrw
Copy link

commented Jun 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 5, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 6, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.