> 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
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 do
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 want
: 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
conf
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 h
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 :
>
> gradle/validation/versions-props-sorted.gradle
> -- will fail if you add a comment to this file.
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
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 so
+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. L
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
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 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
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 depende
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 lo
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 genera
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 discre
>
> 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 o
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 instab
17 matches
Mail list logo
