To be honest, I rarely update dependency versions Log4j. I recently did it for the Spring support to pick up some fixes that were required. But I am just not sure how we can tell a user that a current version of Log4j is compatible with an older version of a component if we are only using the latest version. Many of our uses do not update their dependencies en masse and only do it when they want or need a feature in a newer release or because of a security scan. That said, I also understand that some projects aren’t too careful about backward compatibility so you can’t be sure you work with a newer version either. But I am just not comfortable telling a user a) try it and see or b) we only support the versions included in the release.
Ralph > On Sep 17, 2020, at 9:24 PM, Matt Sicker <boa...@gmail.com> wrote: > > I’ll say that we also use Dependabot and some custom bot at work for > dependency updates, and I’m one of the evangelists, but it’s to ensure that > things get security updates which would otherwise clog up the resources of > the limited number of engineers working on security in the first place. I > sometimes point out various Apache projects people could be using to avoid > dependency update pains due to a wider culture of avoiding Jar Hell here > compared to generic Java OSS projects, too, for those who can’t keep up > with the insecure and quickly changing libraries out there (which becomes a > bigger issue when you try to maintain API compatibility over time). > > On Thu, Sep 17, 2020 at 21:03 Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Thu, Sep 17, 2020 at 8:49 PM Ralph Goers <ralph.go...@dslextreme.com> >> >> wrote: >> >> >> >>> I very much like all the emails due to dependabot. Furthermore, if it is >> >>> going to create 25 PRs then it also needs to create Jira issues and >> include >> >>> updates to changes.xml, otherwise it just creates a lot of work. >> >>> Furthermore, I have never been in favor of updating dependencies versions >> >>> without a compelling reason. >> >>> >> >>> On the other hand, if it generated reports that we could include in the >> >>> web site indicating we were compatible or if there are problems I would >> >>> find that much more valuable. I would really prefer to have the versions >> >>> set to the lowest version we support but have verified that it runs with >> >>> newer versions. IOW, if dependabot could just perform its test builds and >> >>> document the results that would be great. >> >> >> >> >> >> This is basically what we have enabled for most components over at Apache >> >> Commons. Each component first started with >> >> the file .github/workflows/maven.yml which let GitHub run builds for PR and >> >> branches. Then we added .github/dependabot.yml which let Dependabot create >> >> PRs (from branches). Once in a while I look at PRs like I would any set of >> >> PRs and decide what to bring in. Just like any other PR, once I bring one >> >> in, I add an entry to changes.xml. I do not create Jiras if there is none >> >> for a PR as I see no benefit since some of the site and release notes are >> >> generated based on changes.xml. The site also generates a page from JIRA >> >> but there is no sync of changes.xml and JIRA. >> >> >> >> Gary >> >> >> >> >> >>> I also wouldn’t mind if it created PRs when a dependency has a CVE and >> >>> needs to be updated due to that (hence increasing the lowest version we >> >>> support). >> >>> >> >>> I know Gary loves dependabot and always wants everything at the latest >> >>> version. What do others think? >> >>> >> >>> Ralph >> >>> >> >> -- > Matt Sicker <boa...@gmail.com>
