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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: Increase Renovate minimumReleaseAge to 7 days #1463

Open
2 tasks done
JoshuaKGoldberg opened this issue Apr 13, 2024 · 1 comment
Open
2 tasks done
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request

Comments

@JoshuaKGoldberg
Copy link
Owner

Bug Report Checklist

Overview

For a while now, this template has set Renovate's minimumReleaseAge to 3 days. That's the time threshold for an npm package to be unable to be unpublished. It also has the nice benefit of giving some time for the community to catch & patch a malicious version of a previously ok package.

But, 3 days isn't a super long amount of time. If something releases on a Friday then folks might not have fully caught+patched it by Monday. I've been thinking for a while of increasing it to a full week.

Request: every place in this repo that says "3 days" should instead say "7 days". That includes .github/renovate.json and createDotGitHubFiles.ts.

Additional Info

See docs on: https://docs.renovatebot.com/configuration-options/#minimumreleaseage

@JoshuaKGoldberg JoshuaKGoldberg added good first issue Good for newcomers, please hop on! type: feature New enhancement or request status: accepting prs Please, send a pull request to resolve this! labels Apr 13, 2024
@rubiesonthesky
Copy link
Contributor

I don't think setting minimumReleaseAge to 7 days will help with the case you are thinking. If library publishes version X on Friday, but then patches it on Monday then using 7 minimum 7 days will mean: Your project will update to broken version on next Friday and it will get the fixed version on next Monday. So you are in any case lagging behind and you can get some broken version.

Better ways to handle this would be to disable automerge or disabling automerge for major versions, so you could be more sure that there is no breaking changes. But neither is really what you are hoping here. :/

@JoshuaKGoldberg JoshuaKGoldberg added status: in discussion Not yet ready for implementation or a pull request and removed good first issue Good for newcomers, please hop on! status: accepting prs Please, send a pull request to resolve this! labels Apr 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request
Projects
None yet
Development

No branches or pull requests

2 participants