Why use this over Dependabot or Renovate?

[erawhctim]

just curious - the README mentions "single source of truth" as the motivator for this tool, but isn't that also how Dependabot and Renovate work?

[bishiboosh]

Honestly, the main difference is that Caupain gives a complete report and doesn't take any action by itself. The use case at Deezer was that we couldn't really use Renovate or Dependabot because we can't update our dependencies atomically, due to the regression testing needed.
Our dependency update workflow is that we check once every two sprints, deeply analyse the changelogs, and update what's deemed safe. So we needed a quick tool that just gives us what's to update, and lets us do the rest of the work. We were using Ben Mane's plugin once that does the same kind of thing, but it's waaaaaay slower due to plugging directly into Gradle dependency mechanism, whereas in Caupain we directly query the Maven repositories.
In the end, it's not as much a "competitor" to Renovate or Dependabot as a tool that serves another kind of workflow

[bishiboosh]

I didn't want this whole schpiel in the README but that's basically the reason

[erawhctim]

thanks!

[wzieba]

I can add a few cents from my perspective of using CLI tool of this project.

Tldr; why use caupain over Dependabot or Renovate?

• it's quicker
• it's static (doesn't require Gradle build)
• it requires little configuration and maintenance seems to be easy (as no additional dependencies are required)

Here's the longer story: at Android Core team at Automattic we support multiple Android projects. To do this effectively, we rely on multiple automations. caupain gave us possibility to easily get the stats about state of outdated dependencies across all projects.

Every hour we fetch libs.versions.toml and gradle-wrappper.properties, run caupain and feed our Prometheus instance. The main difference and huge advantage of caupain to me is that we don't have to spin up a Gradle build, but instead get all updates statically.

An alternative, that we actually experimented in the past, was to use a Gradle plugin (e.g. ben-manes/gradle-versions-plugin), run a build of each app, and then collect metrics. It's a significantly longer process, takes more of our resources and requires much more maintenance to keep this additional CI job running.

Another alternative, reports from Renovate, sounded like a theoretically valid option, but again it requires more maintenance, report collection and parsing, and in our case, self-hosting Renovate instance. This all combined requires more effort than using Caupain.

Here's an example Grafana dashboard we were able to set up by the data fed by this project, and it works flawlessly:

[ben-manes]

I was always surprised Gradle didn’t build in dependency updates directly. They also kept backlogging parallel resolution of the metadata. At the beginning (gradle 1.0) I assumed the plugin would be a temporary fix making it a fun weekend project, and used their APIs to leverage the platform. Seemed good enough and never thought it would stick around. 🤷‍♂️

[bishiboosh]

@ben-manes honestly, thanks a lot for your plugin, it's been the reliable source of updates for a loooot of time, and the design of Caupain took more than a few ideas from it (especially the selectIf concept, the policy I implemented is a bit of code which has been in my gradle file through companies for a long time now). Your code was really cool and helped me understand a lot about dependencies, but hey, you're constrained by the Gradle process so there's not a lot you can do to make it quicker :)

(and obviously your plugin is probably the only one which is sure to report all updates)

[wzieba]

I second this ☝️. The gradle-versions-plugin was the go-to tool for identifying dependency updates - especially back when there wasn’t a standardized way to declare dependencies. It served us well, even powering some of our early automation experiments.

What sets Caupain apart, and what made a big difference in our setup, is its different approach: instead of relying on Gradle to fetch versions, it parses files statically and queries repositories directly. That shift significantly improved our workflow.

In my comment, I mainly wanted to highlight that difference. But I also want to take a moment to say thank you, @ben-manes, for maintaining and supporting the gradle-versions-plugin over so many years! 🙌

[bishiboosh]

(so glad I got the opportunity to thank you on that plugin, it was probably one of the oldest ones I used and my first foray in both Gradle plugins dev and how dependency resolution worked)

[ben-manes]

btw, you are welcome to send a pr to add yours to related-plugins. Those others were built on top, though some may have migrated off later for their own reasons. I only care that it helps the community, not whether people use my work (its all free hobby stuff after all).

[martinbonnin]

I'll chip in with my 2 cents:

I maintain a lot of libraries and most of the time, I don't want to auto update the dependencies:

• For patches/minors, I feel like this is the responsibility of the final binary producer. They can decide whether they want to upgrade the transitive dependencies or not. As a library, we're not shoving a minor update down their throat. If they want to update, they can easily do so by declaring their own dependency. The opposite (downgrading a transitive dependency) feels a lot more dangerous.
• For major versions, most of them require a new major version of my libraries and shouldn't be automatically bumped either.

Caupain gives me that in a very simple, standalone and fast way. gradle-versions-plugin has been super useful over the years but now that most of my deps are in Maven Central, I like the ability to update versions without having to change my build logic/run a full Gradle build.