You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Ishan Chattopadhyaya <ic...@gmail.com> on 2023/04/02 04:04:01 UTC
Rethinking dependency upgrades
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?
Re: Rethinking dependency upgrades
Posted by Jan Høydahl <ja...@cominvent.com>.
> I believe that the updates only come once a week, and that it's limited to 5 correct? I actually look forward to seeing "what's new" from Solrbot on Monday morning.
Almost. They come every Sunday, are limited to 10 new each hour and a total of 30 concurrent open PRs. See https://github.com/apache/solr/blob/main/.github/renovate.json#L49-L50
Right now there are 2 open, so in practice we get every single dep upgrade since last week.
I am also thrilled about the side-effect it has had to inspect our codebase and ask questions like "why do we need dep X" and slim things down.
It would be interesting to also have some insight into which of our direct and transitive dependencies are "stale", i.e. not updated in years.
I did a quick checkout of 9.0 tag and compared versions.lock with main. Here are the dependencies that are still on the same version in main (excluding test-dependencies): https://paste.apache.org/qfqvf
Could be a great list to walk through, and create JIRAs to deprecate, upgrade or remove our "direct" dependencies that rely on these old versions.
Jan
> 5. apr. 2023 kl. 12:21 skrev Eric Pugh <ep...@apache.org>:
>
> I believe that the updates only come once a week, and that it's limited to 5 correct? I actually look forward to seeing "what's new" from Solrbot on Monday morning.
>
> It's also opened my eyes to how many dependencies we have, and I think helps encourage us to look at where we can slim things down.
>
> I hope we can learn which libraries are in the "release early/release often" category, and maybe we check for updates much less frequently.
>
> I've been very encourage by how SolrBot has worked for us in pushing us to having a more modern codebase.
>
>
>
> On 2023/04/05 09:56:16 Jan Høydahl wrote:
>> Hi,
>>
>> Hoss, I see what you're getting at.
>>
>> So far we kept it simple and only suggest PRs on main branch, and let committer backport at own discretion.
>>
>> It has a few downsides:
>> * Won't get PRs for deps that are removed in main but still supported in 9x
>> * If we e.g. upgraded main to jetty 11 but wanted 9x to stay on jetty 10, there would not no 10.x.y upgrade PRs
>>
>> Renovate opens separate PR for major ver, but folds patch/minor upgrades into same PR. Thus if we wanted to be conservative for an upcoming release and only do a bugfix upgrade, there may not be a PR for it if a newer minor version exists.
>> Renovate has options for these things, see docs https://docs.renovatebot.com/faq/#renovates-default-behavior-for-majorminor-releases if we want separate bugfix PRs.
>> But if we should have separate PRs for bugfixes and separate PRs for main and branch_9x, then I think the amount would explode somewhat.
>>
>> We currently have a general 5-day delay since a release. Could be we could configure different delays for major/minor/patch, have a look at the documentation site I linked to and see if you believe it is possible. I sometimes get confused by the large amount of configuration options.
>>
>> Jan
>>
>>
>>> 4. apr. 2023 kl. 22:47 skrev Chris Hostetter <ho...@fucit.org>:
>>>
>>>
>>> : 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.
>>>
>>> That feels like it just pushes all of the work, and risk of discovering
>>> conflicts in dep upgrades, and risk of uncovering bugs, until right before
>>> the release.
>>>
>>> The soon we try upgrades (and the longer we have people & jenkins)
>>> testing out the upgraded deps _before_ the release, the less stress/delay
>>> when it comes time to acctauly cut and RC.
>>>
>>>
>>> As someone who isn't really familiar with the solrbot PRs, the
>>> question/proposal i would make is:
>>>
>>> - Can it "slowly" be "agressive" about upgrade suggestions on 'main'
>>> - aggresive = suggest every possible upgrade to latest possible version
>>> - slowly = wait to suggest until at least X days after new version is
>>> released (in case 3rd party does a bug fix release)
>>> - Can it "quickly" be "conservative" about upgrade suggestions on '9x'
>>> - conservative = only suggest minor upgrades
>>> - quickly = suggest them as soon as they are available
>>>
>>> ?
>>>
>>> Or maybe, to think about the problem differnetly (independent of
>>> solr branch) but w/the same general goals:
>>>
>>> - can it suggest bugfix upgrades (A.M.X -> A.M.Y) ASAP
>>> - can it suggest minor upgrades (A.M.X -> A.N.0) only after some
>>> small number of days delay since last A.N.? release (to wait for a
>>> possible A.N.1 bug fix)
>>> - can it suggest major upgrades (A.M.X -> B.0.0) only after some larger
>>> number of days delay since last last B.?.? release (same reason)
>>>
>>>
>>>
>>> -Hoss
>>> http://www.lucidworks.com/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by Eric Pugh <ep...@apache.org>.
I believe that the updates only come once a week, and that it's limited to 5 correct? I actually look forward to seeing "what's new" from Solrbot on Monday morning.
It's also opened my eyes to how many dependencies we have, and I think helps encourage us to look at where we can slim things down.
I hope we can learn which libraries are in the "release early/release often" category, and maybe we check for updates much less frequently.
I've been very encourage by how SolrBot has worked for us in pushing us to having a more modern codebase.
On 2023/04/05 09:56:16 Jan Høydahl wrote:
> Hi,
>
> Hoss, I see what you're getting at.
>
> So far we kept it simple and only suggest PRs on main branch, and let committer backport at own discretion.
>
> It has a few downsides:
> * Won't get PRs for deps that are removed in main but still supported in 9x
> * If we e.g. upgraded main to jetty 11 but wanted 9x to stay on jetty 10, there would not no 10.x.y upgrade PRs
>
> Renovate opens separate PR for major ver, but folds patch/minor upgrades into same PR. Thus if we wanted to be conservative for an upcoming release and only do a bugfix upgrade, there may not be a PR for it if a newer minor version exists.
> Renovate has options for these things, see docs https://docs.renovatebot.com/faq/#renovates-default-behavior-for-majorminor-releases if we want separate bugfix PRs.
> But if we should have separate PRs for bugfixes and separate PRs for main and branch_9x, then I think the amount would explode somewhat.
>
> We currently have a general 5-day delay since a release. Could be we could configure different delays for major/minor/patch, have a look at the documentation site I linked to and see if you believe it is possible. I sometimes get confused by the large amount of configuration options.
>
> Jan
>
>
> > 4. apr. 2023 kl. 22:47 skrev Chris Hostetter <ho...@fucit.org>:
> >
> >
> > : 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.
> >
> > That feels like it just pushes all of the work, and risk of discovering
> > conflicts in dep upgrades, and risk of uncovering bugs, until right before
> > the release.
> >
> > The soon we try upgrades (and the longer we have people & jenkins)
> > testing out the upgraded deps _before_ the release, the less stress/delay
> > when it comes time to acctauly cut and RC.
> >
> >
> > As someone who isn't really familiar with the solrbot PRs, the
> > question/proposal i would make is:
> >
> > - Can it "slowly" be "agressive" about upgrade suggestions on 'main'
> > - aggresive = suggest every possible upgrade to latest possible version
> > - slowly = wait to suggest until at least X days after new version is
> > released (in case 3rd party does a bug fix release)
> > - Can it "quickly" be "conservative" about upgrade suggestions on '9x'
> > - conservative = only suggest minor upgrades
> > - quickly = suggest them as soon as they are available
> >
> > ?
> >
> > Or maybe, to think about the problem differnetly (independent of
> > solr branch) but w/the same general goals:
> >
> > - can it suggest bugfix upgrades (A.M.X -> A.M.Y) ASAP
> > - can it suggest minor upgrades (A.M.X -> A.N.0) only after some
> > small number of days delay since last A.N.? release (to wait for a
> > possible A.N.1 bug fix)
> > - can it suggest major upgrades (A.M.X -> B.0.0) only after some larger
> > number of days delay since last last B.?.? release (same reason)
> >
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
Hoss, I see what you're getting at.
So far we kept it simple and only suggest PRs on main branch, and let committer backport at own discretion.
It has a few downsides:
* Won't get PRs for deps that are removed in main but still supported in 9x
* If we e.g. upgraded main to jetty 11 but wanted 9x to stay on jetty 10, there would not no 10.x.y upgrade PRs
Renovate opens separate PR for major ver, but folds patch/minor upgrades into same PR. Thus if we wanted to be conservative for an upcoming release and only do a bugfix upgrade, there may not be a PR for it if a newer minor version exists.
Renovate has options for these things, see docs https://docs.renovatebot.com/faq/#renovates-default-behavior-for-majorminor-releases if we want separate bugfix PRs.
But if we should have separate PRs for bugfixes and separate PRs for main and branch_9x, then I think the amount would explode somewhat.
We currently have a general 5-day delay since a release. Could be we could configure different delays for major/minor/patch, have a look at the documentation site I linked to and see if you believe it is possible. I sometimes get confused by the large amount of configuration options.
Jan
> 4. apr. 2023 kl. 22:47 skrev Chris Hostetter <ho...@fucit.org>:
>
>
> : 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.
>
> That feels like it just pushes all of the work, and risk of discovering
> conflicts in dep upgrades, and risk of uncovering bugs, until right before
> the release.
>
> The soon we try upgrades (and the longer we have people & jenkins)
> testing out the upgraded deps _before_ the release, the less stress/delay
> when it comes time to acctauly cut and RC.
>
>
> As someone who isn't really familiar with the solrbot PRs, the
> question/proposal i would make is:
>
> - Can it "slowly" be "agressive" about upgrade suggestions on 'main'
> - aggresive = suggest every possible upgrade to latest possible version
> - slowly = wait to suggest until at least X days after new version is
> released (in case 3rd party does a bug fix release)
> - Can it "quickly" be "conservative" about upgrade suggestions on '9x'
> - conservative = only suggest minor upgrades
> - quickly = suggest them as soon as they are available
>
> ?
>
> Or maybe, to think about the problem differnetly (independent of
> solr branch) but w/the same general goals:
>
> - can it suggest bugfix upgrades (A.M.X -> A.M.Y) ASAP
> - can it suggest minor upgrades (A.M.X -> A.N.0) only after some
> small number of days delay since last A.N.? release (to wait for a
> possible A.N.1 bug fix)
> - can it suggest major upgrades (A.M.X -> B.0.0) only after some larger
> number of days delay since last last B.?.? release (same reason)
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by Chris Hostetter <ho...@fucit.org>.
: 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.
That feels like it just pushes all of the work, and risk of discovering
conflicts in dep upgrades, and risk of uncovering bugs, until right before
the release.
The soon we try upgrades (and the longer we have people & jenkins)
testing out the upgraded deps _before_ the release, the less stress/delay
when it comes time to acctauly cut and RC.
As someone who isn't really familiar with the solrbot PRs, the
question/proposal i would make is:
- Can it "slowly" be "agressive" about upgrade suggestions on 'main'
- aggresive = suggest every possible upgrade to latest possible version
- slowly = wait to suggest until at least X days after new version is
released (in case 3rd party does a bug fix release)
- Can it "quickly" be "conservative" about upgrade suggestions on '9x'
- conservative = only suggest minor upgrades
- quickly = suggest them as soon as they are available
?
Or maybe, to think about the problem differnetly (independent of
solr branch) but w/the same general goals:
- can it suggest bugfix upgrades (A.M.X -> A.M.Y) ASAP
- can it suggest minor upgrades (A.M.X -> A.N.0) only after some
small number of days delay since last A.N.? release (to wait for a
possible A.N.1 bug fix)
- can it suggest major upgrades (A.M.X -> B.0.0) only after some larger
number of days delay since last last B.?.? release (same reason)
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by Mike Drob <md...@mdrob.com>.
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 <ds...@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 <ja...@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 <ds...@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 <kr...@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 <gu...@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 <ho...@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 <
> gerlowskija@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 <kr...@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 <
> > >>>>>> ichattopadhyaya@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-unsubscribe@solr.apache.org
> > >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> http://www.needhamsoftware.com (work)
> > >>> http://www.the111shift.com (play)
> > >>>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
Re: Rethinking dependency upgrades
Posted by Kevin Risden <kr...@apache.org>.
I went back through versions.props and I think there are only two that can
be removed:
commons-text - https://github.com/apache/solr/pull/1539 - this one is simple
joda-time - https://github.com/apache/solr/pull/1540 - this one is slightly
more complicated
But out of the 76 lines we define only having two is pretty good.
Kevin Risden
On Mon, Apr 3, 2023 at 4:49 PM Jan Høydahl <ja...@cominvent.com> wrote:
> This PR will allow comments in versions.props:
> https://github.com/apache/solr/pull/1537, as long as the rest of the
> lines are sorted...
>
> Jan
>
> > 3. apr. 2023 kl. 22:09 skrev David Smiley <ds...@apache.org>:
> >
> > gradle/validation/versions-props-sorted.gradle
> > -- will fail if you add a comment to this file.
>
>
Re: Rethinking dependency upgrades
Posted by Jan Høydahl <ja...@cominvent.com>.
This PR will allow comments in versions.props: https://github.com/apache/solr/pull/1537, as long as the rest of the lines are sorted...
Jan
> 3. apr. 2023 kl. 22:09 skrev David Smiley <ds...@apache.org>:
>
> gradle/validation/versions-props-sorted.gradle
> -- will fail if you add a comment to this file.
Re: Rethinking dependency upgrades
Posted by David Smiley <ds...@apache.org>.
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 <ja...@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 <ds...@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 <kr...@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 <gu...@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 <ho...@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 <gerlowskija@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 <kr...@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 <
> >>>>>> ichattopadhyaya@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-unsubscribe@solr.apache.org
> >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> http://www.needhamsoftware.com (work)
> >>> http://www.the111shift.com (play)
> >>>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Rethinking dependency upgrades
Posted by Jan Høydahl <ja...@cominvent.com>.
+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 <ds...@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 <kr...@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 <gu...@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 <ho...@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 <ge...@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 <kr...@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 <
>>>>>> ichattopadhyaya@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-unsubscribe@solr.apache.org
>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by David Smiley <ds...@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 <kr...@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 <gu...@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 <ho...@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 <ge...@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 <kr...@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 <
> > > > > ichattopadhyaya@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-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > > >
> > >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
> >
>
Re: Rethinking dependency upgrades
Posted by Kevin Risden <kr...@apache.org>.
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 <gu...@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 <ho...@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 <ge...@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 <kr...@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 <
> > > > ichattopadhyaya@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-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: Rethinking dependency upgrades
Posted by David Smiley <ds...@apache.org>.
Good idea Gus!
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Apr 3, 2023 at 11:30 AM Gus Heck <gu...@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 <ho...@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 <ge...@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 <kr...@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 <
> > > > ichattopadhyaya@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-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
Re: Rethinking dependency upgrades
Posted by Gus Heck <gu...@gmail.com>.
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 <ho...@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 <ge...@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 <kr...@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 <
> > > ichattopadhyaya@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-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Rethinking dependency upgrades
Posted by Houston Putman <ho...@apache.org>.
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 <ge...@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 <kr...@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 <
> > ichattopadhyaya@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-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Rethinking dependency upgrades
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <kr...@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 <
> ichattopadhyaya@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-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Rethinking dependency upgrades
Posted by Kevin Risden <kr...@apache.org>.
>
> 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 <
ichattopadhyaya@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?
>