What I would like to know is what expectations are we giving our users? At work, I could never sell this unless our build and QA validates a product for all versions in a range, for every release.
I am sure we are not proposing that and that the build... does what? Pick the latest in the range? Latest by what measure? Release date, lexicographical sort of version strings? If we release with a dep on a range 2.1 - 2.4 and a new release 2.1.1 comes out after our release that breaks our code, then what? Now I'm worried. Please help me understand. Thank you, Gary On Wed, Jul 29, 2020, 22:57 Ralph Goers <ralph.go...@dslextreme.com> wrote: > 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> > > > > >
