[Feature request] Opt out minor and patch versions

[bustikiller]

For organizations with many projects sometimes it is hard to keep track of all the dependency updates. I would like to get only updates for major & security releases (opt-out from minor and patch versions), configurable per project.

[feelepxyz]

@bustikiller ah yeah there's currently no way to disable all minor and patch releases. From experience upgrading to major releases without going through minor/patch releases usually makes the transition more painful as the minors sometimes introduce deprecations to make the update easier.

Not ideal but you could reduce some noise by ignoring minor versions of the most frequently updated dependencies from the PR with @dependabot ignore this minor - you would still hear about the next minor but silence all patch releases.

I'll keep this open to see if anyone else is also keen on this.

Thanks for the suggestion!

[Floppy]

@bustikiller perhaps you might reduce the noise while still getting the benefit of the updates by letting dependabot auto-merge minor updates? That's configurable per project, and separately for dev/production dependencies too.

[eddiej]

+1 for this feature request, the ability to ignore patch version updates would be great.

[NilsJPWerner]

+1 for ignoring patch updates. This would be great to configure in the config.yml

[repi]

We at Embark would love to be able to have Dependabot skip patch versions as well for our Rust projects. They create to much noise as multiple per day are updated and it is too much overhead to get a PR for each update, even if it is just weekly.

So for patch version updates we handle that manually ourselves through frequent cargo update rolled together updates multiple times per week. But want great Dependabot PRs for major and minor version upgrades.

[trevtrich]

Per what @Floppy mentioned, would auto-merging patch updates take care of the noise problem for folks, or is that not an option in your organization? We've found that auto-merging minor and patch after tests pass forces good testing practices primarily in that it forces you to rely on your tests. Like I mentioned, though, not possible in every org.

[bustikiller]

@richardson-trevor I understand the benefits of doing that, but this would only work if all dependencies followed semantic versioning. We have experienced patch version upgrades that broke production environments. For this reason, we prefer to test every dependency upgrade before going live. But it is not feasible for us to test every dependency upgrade if we have dozens every month.

I would prefer to have fewer dependency upgrades that we can properly test.

[trevtrich]

That's fair. We do shoot for our tests telling us that one of our deps is about to break production if there was a breaking change, but there are no-doubt cases that do slip through the cracks (or get stubbed out, which has been the source of our issues). In our situation we're able to kick out a new release to prod very quickly if this comes up, but this has only happened a few times in our course of about two years of moving to this mindset.

[trivikr]

Is this feature being worked on?
I tested dependabot in one of my personal repos, and too many PRs created was the only concern. Details in aws/aws-sdk-js-v3#280 (comment)

[greysteil]

Not at the moment. We're a tiny team and are prioritizing getting Automated Security Fixes working for all GitHub repos and fully integrating Dependabot into GitHub.

[trivikr]

Thanks @greysteil for the response

Is there an issue marked with good-first-issue or help-wanted for this request which contributors can look at (probably in dependabot-core)?
If not, can you create one with links to which code contributors can look at to provide this support?

[greysteil]

Frustratingly this one would need changes to our backend codebase, which isn't open source, rather than Dependabot Core.