That is interesting. I hadn’t thought about using version ranges. That might accomplish what we need.
Ralph > On Jul 29, 2020, at 6:39 PM, Matt Sicker <boa...@gmail.com> wrote: > > Isn't that what Maven version ranges are for? > > On Wed, 29 Jul 2020 at 19:34, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >> >> >>> On Jul 29, 2020, at 3:28 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>> On Wed, Jul 29, 2020 at 4:33 PM Matt Sicker <boa...@gmail.com> wrote: >>> >>>> ICLAs aren't required for trivial contributions, though they are >>>> required for committers. Are bots committers? Alternatively, if we >>>> only merge PRs from the bot using the Merge button rather than the >>>> @dependabot comment commands, then that ensures a committer is the one >>>> who introduces the merge commit itself into the git repo. >>>> >>> >>> IMO, a committer needs to validate the PR and push the merge button. >>> >>> >>>> >>>> As for dependencies, I've been facing an opposite constraint: the >>>> endless security scanners complaining about every possible CVE or >>>> proprietary vulnerability published about OSS libraries that have >>>> patches available. As more and more companies embrace security, one of >>>> the low-hanging fruits of software development is keeping dependencies >>>> up to date [1]. As for ensuring things still work in older versions of >>>> a library, perhaps we should have some way to run tests with old >>>> versions of the library periodically to ensure we aren't breaking >>>> compatibility unnecessarily. >>>> >>> >>> At work, we have tooling that checks for CVEs on all third party libraries >>> we deliver. A CVE on an old library will cause us to update it. >> >> >> Yes, and that is the key. The version is controlled by your application. >> You don’t rely on the version provided by Log4j. It really shouldn’t matter >> what Log4j has for transitive dependencies. A good application should be >> declaring the version of every dependency that will end up as part of the >> app. >> >> But you guys are correct in that a Log4j release should be compatible with >> the latest release of any components it is using. But somehow users need to >> be informed that they can upgrade Log4j without having to be required to >> update their other dependencies if they are compatible. >> >> Ralph >> >> >> > > > -- > Matt Sicker <boa...@gmail.com> >
