I'm no Maven expert, so the only thing I could think of that might be flexible enough to match our desire to test compatibility with older dependencies and their recent versions. It'd have to be on a case-by-case basis as some libraries follow SemVer while others don't.
On Thu, 30 Jul 2020 at 08:03, Gary Gregory <garydgreg...@gmail.com> wrote: > > 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> > > > > > > > > > -- Matt Sicker <boa...@gmail.com>
