I'm a Rust developer and I see some projects using Dependabot. The reason why I'm not adopting it for the projects I maintain is as follows: * In library proje

I'm a Rust developer and I see some projects using Dependabot. The reason why I'm not adopting it for the projects I maintain is as follows: * In library projects, many Dependabot PRs are just increasing the patch version of the library. Unless they require new features added in the new version, I think libraries shouldn't do this. This does actually more harm than good because sometimes, downstream might not want to update the patch version of a dependency but might want to update your library. The only argument in favour is that you might miss it if your library requires a new version, but in general, libraries should strive to require a larger range of versions. A hammer is only more useful if it works with nails bought 30 years ago. * In application projects, I prefer doing dependency updates in bulk rather than as soon as possible: Replacing a dependency high in the tree causes all its dependents to be rebuilt, which causes CPU overhead for everyone who is building my code: Sometimes you need to rebase a PR and you shouldn't have to wait for the dependencies to compile because master branch had to do some update. Similarly, when you bisect some regression it's annoying if you have to rebuild the dependencies of the project on every bisection step. Thus I'm generally waiting to do dependency updates (cargo update as well as semver-noncompliant version updates) once per month. It's no strict rule but still a rule. Exceptions are e.g. when a dependency fixes a bug that affects my code or when a dependency update requires nontrivial work. I rather do that sooner before it bitrots.