I have mixed feelings. Gary has been manually doing this for quite a while and I have always had concerns - besides driving his commit count artificially through the roof.
Managing dependencies really needs to be managed carefully. When we upgrade a dependency that effectively becomes the minimum supported version. In that sense we are upgrading dependencies way too fast. At the same time, we need to insure that we don’t have problems with new releases. As such we really need two versions of the parent pom - one that is used for verifying the latest versions of dependencies and one that is used for the release that specifies the minimum supported version (typically this would be expressed as a version range). I’m also concerned because some dependencies upgrade their minimum required JDK version in a minor release. That happened with the Flume 1.8 release. So we cannot upgrade to that version in the release-2.x branch, although our users can if they want to. We also ran into a problem with SLF4J. The latest release dropped a class that we use. We have modified the code to support the latest releases but we require the last release that had the class to compile. Also, our process has always been to create a Jira for everything, including updating dependency versions, and including them in changes.xml. It looks like this tool doesn’t do either of these things. Ralph > On Mar 25, 2019, at 9:24 AM, Matt Sicker <[email protected]> wrote: > > Hi all, > > Various Jenkins projects have been using Dependabot [1] to > automatically make PRs to update dependencies. We could use this for > most of our components it looks like. What do you think about adopting > use of this bot? > > [1]: https://dependabot.com/ > > -- > Matt Sicker <[email protected]> >
