I think for a lot of us the rapid release cycle of other projects is surprising coming from our ASF context. Here a release takes three votes and at least three days and comparatively quite a bit of process. For some other project, a release involves as little as clicking a button to make a github tag and then everything else flows from there. So for those projects, a single PR or patch can be enough to precipitate a release, while we batch hundreds of PRs before our next release.
This is not to say one way or the other is better, but to highlight the difference in mental models and processes between our project and others. So even though we release roughly quarterly, it is not fair (although highly tempting) to expect that our dependencies also update on a similar cadence. Mike On Mon, Apr 3, 2023 at 3:10 PM David Smiley <dsmi...@apache.org> wrote: > gradle/validation/versions-props-sorted.gradle > -- will fail if you add a comment to this file. It insists that the file > is sorted. It also generates the file sorted if it isn't. So if we want > to support comments, we'll need to remove generating the file and remove > the comments in checking for sorted order. > > Another point to note is that we'll probably have fewer dependency bot PRs > after the longer backlog of dated dependencies is addressed. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Mon, Apr 3, 2023 at 4:01 PM Jan Høydahl <jan....@cominvent.com> wrote: > > > +1 to keeping dependencies up to date. > > > > But we don't necessarily need to do it every week, if people feel it is > > noisy. We could disable the bot until we start thinking about a new > > release, and then get a ton of upgrades to merge for the new release. > > Personally I prefer smaller bulks each week. Less to manage for RM and > more > > time to test upgrades. > > > > > So an outcome here is: groom versions.properties to not have needless > > references to transitive dependencies. > > > > Absolutely, we have done so several times already, and there may be even > > more left. > > > > > It's too bad the format of this file doesn't support comments so that > we > > > > The versions.props file actually supports #comments on separate lines, so > > it could be a good idea to do that. Perhaps maintain a separate section > at > > the bottom for temporary transitive overrides? > > > > Jan > > > > > 3. apr. 2023 kl. 18:30 skrev David Smiley <dsmi...@apache.org>: > > > > > > 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) > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > >
