I wasn't thinking of automating this fully at any point. The bot does file PRs for each dependency individually. I'm not sure how configurable everything is, but I do like the sound of having multiple dependency management profiles for compatibility testing purposes.
On Mon, 25 Mar 2019 at 13:07, Gary Gregory <[email protected]> wrote: > > This reminds me: What happened to Apache Gump? Didn't it handle this? > > Gary > > On Mon, Mar 25, 2019 at 2:02 PM Gary Gregory <[email protected]> wrote: > > > There room for automation in this area, but I only seen it as an > > informative step for now. Like the tool saying "I've ran the build with > > this change and it's green/red". Today, without this tool, I could see a > > tool doing : > > - create a branch for a change and push it, create a PR > > - look at what GitHub/Travis-CI reports > > > > then you, the dev: > > > > - accept/reject the PR > > > > This would only be done one dep change at a time. IOW, only once you've > > accepted/rejected a dep change would you move on to the next one. > > > > Gary > > > > On Mon, Mar 25, 2019 at 1:46 PM Ralph Goers <[email protected]> > > wrote: > > > >> 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]> > >> > > >> > >> -- Matt Sicker <[email protected]>
