> Is there a compelling reason to prefer Renovate for Jenkins core Java dependencies?
dependabot and renovate can manage Java dependencies equally fine, the drawback for frontend deps apply here too, you get one PR each, if that is a reasonable and frequent concern (it is not from what I've seen). Although, I don't think we need two bots alongside for different package ecosystems, when one bot can do both. If renovate doesn't turn out well for Java dependency updates or exposes unforeseen issues that can't be fixed, we can still switch back to dependabot for java dependency updates. On Monday, 18 July 2022 at 23:38:37 UTC+2 m...@basilcrow.com wrote: > +1 for Renovate for JavaScript dependencies, for the reasons you have > pointed out: it does a better job of combining multiple updates > together, increasing the success rate of the resulting proposed > change. > > Is there a compelling reason to prefer Renovate for Jenkins core Java > dependencies? I can think of one reason to prefer Dependabot in this > scenario: it is consistent with our technology choice for managing > Jenkins plugin Java dependencies. Using the same technology to manage > Jenkins core Java dependencies and Jenkins plugin Java dependencies > buys us the advantage of consistency and familiarity. For example, > over the years I have become familiar with Dependabot's > implementation, includings both its strengths and weaknesses, and I > have stepped through its Ruby code in a debugger on more than one > occasion to solve some mysteries (despite the fact that I am not much > of a Ruby programmer). Switching to a new technology stack for > managing Jenkins core Java dependencies while retaining the existing > technology stack for managing Jenkins plugin Java dependencies would > increase cognitive load by forcing developers to learn a new > technology stack (Renovate) while not allowing them to forget the > technology stack they already know (Dependabot). This wouldn't be out > of the question if the advantages were compelling enough, but you did > not present an argument that they were. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2f480f44-920c-4523-987d-8cd598477fa7n%40googlegroups.com.
