So an outcome here is: groom versions.properties to not have needless references to transitive dependencies. It's too bad the format of this file doesn't support comments so that we can explain our justification for listing a transitive dependency. Maybe that would be easy for us to add.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Apr 3, 2023 at 12:26 PM Kevin Risden <kris...@apache.org> wrote: > solrbot only updates things in versions.props. The PRs have found a few > cases where we could remove a few old transitive dependency pins in > versions.props. versions.props only has direct dependencies so not going > out of the way to upgrade transitive dependencies. That being said, the > direct dependency upgrades do in many cases upgrade transitive dependencies > (as seen in versions.lock) but the PRs are not specific for that. > > Kevin Risden > > > On Mon, Apr 3, 2023 at 11:30 AM Gus Heck <gus.h...@gmail.com> wrote: > > > The only thing I think I would add is that perhaps we should think of > > things in terms of upgrading our direct dependencies. That ensures the > > proper testing at the preceding levels. Updates of transitive deps are > > somewhat more risky, though justifiable if there is a valid security > > concern such as log4shell or similar of course. > > > > On Mon, Apr 3, 2023 at 10:47 AM Houston Putman <hous...@apache.org> > wrote: > > > > > I agree with Jason and Kevin that it's better to err on the side of > > > updating dependencies faster than updating them slower. > > > > > > We have (hopefully) comprehensive testing for a lot of the features > that > > > these dependencies are used for, and as Jason said we have ultimate > > > discretion in merging. > > > > > > In general I'm surprised these libraries have so many updates, I was > not > > > imagining that we'd get a dozen updates a week. > > > > > > - Houston > > > > > > On Mon, Apr 3, 2023 at 9:01 AM Jason Gerlowski <gerlowsk...@gmail.com> > > > wrote: > > > > > > > Hi all, > > > > > > > > New releases of dependencies can introduce new bugs for sure. But I > > > > think the rationale is generally that on the whole, a new release of > > > > dependency Foo is going to fix more than it breaks (otherwise why > > > > would the Foo project have done the release). > > > > > > > > Particularly since we still have discretion in merging (or ignoring) > > > > these PRs, configuring their frequency, etc. I don't have any > > > > objections with how things are done currently. > > > > > > > > Best, > > > > > > > > Jason > > > > > > > > On Sun, Apr 2, 2023 at 1:04 AM Kevin Risden <kris...@apache.org> > > wrote: > > > > > > > > > > > > > > > > > What if latest versions of libraries have vulnerabilities or bugs > > or > > > > > > instabilities that have yet to be uncovered > > > > > > > > > > > > > > > > So by not upgrading to the latest version - you are making the > choice > > > to > > > > > purposefully avoid known bug fixes and improvements as well. I > don't > > > > think > > > > > any library makes a release on purpose that doesn't address any > bugs > > or > > > > > fixes that could be useful. > > > > > > > > > > Solrbot is aggressively opening dependency upgrade PRs > > > > > > > > > > > > > > > > Aggressively is an interesting characterization. Factually PRs are > > > being > > > > > opened on a configurable basis that includes different frequencies > > for > > > > more > > > > > often upgraded dependencies (ie: AWS sdk). The PRs are opened so > that > > > > there > > > > > is a lag and its not immediate for new versions. > > > > > > > > > > The more frequently we upgrade the easier it is to spot issues and > > > > > problems. Our randomized tests need time to go through different > > > > > combinations of libraries. > > > > > > > > > > So I am 100% for the approach so far. > > > > > > > > > > Kevin Risden > > > > > > > > > > > > > > > On Sun, Apr 2, 2023 at 12:04 AM Ishan Chattopadhyaya < > > > > > ichattopadhy...@gmail.com> wrote: > > > > > > > > > > > Solrbot is aggressively opening dependency upgrade PRs. I think > the > > > > general > > > > > > direction we're heading towards is to upgrade all dependency to > the > > > > latest > > > > > > available versions. > > > > > > > > > > > > Should we pause to rethink if that's the best idea? What if > latest > > > > versions > > > > > > of libraries have vulnerabilities or bugs or instabilities that > > have > > > > yet to > > > > > > be uncovered? By letting other projects use them first, and by > > being > > > > > > conservative in upgrading, we can ensure better stability and > > > > reliability > > > > > > for our releases. > > > > > > > > > > > > As a search engine, we don't need to upgrade each and every > library > > > at > > > > the > > > > > > earliest opportunity all the time. > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > > > > > > > -- > > http://www.needhamsoftware.com (work) > > http://www.the111shift.com (play) > > >
