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]> >> > >> >>
