So I think we can leave it as it is. The only problem would be if a user has a project using Beam and different Solr dependency at once - then Beam would enforce him to use the version Beam does. Should I change the dependency to 'provided' to cover this case? Earlier we had 5.5.2 version as compile dependency and there were no complains.
On 2020/10/28 09:09:42, Piotr Szuberski <piotr.szuber...@polidea.com> wrote: > Response from Solr: > > Generally speaking, SolrJ has been very compatible communicating to many > backend Solr server versions. I wish we tracked problems about this > specifically somewhere, but I don't think we do. I suggest simply using the > latest SolrJ release. If you find issues, report them. Again, assuming > SolrJ, it's good to have some flexibility on which SolrClient subclass is > used. There's Cloud vs not (i.e. standalone), there's newer HTTP2 vs not. > There's Cloud talking directly to ZooKeeper for cluster state, or there's via > Solr HTTP. > > On 2020/10/23 20:14:22, Kenneth Knowles <k...@apache.org> wrote: > > This might be a good question for u...@solr.apache.org and/or > > d...@solr.apache.org, too. > > > > Kenn > > > > On Fri, Oct 23, 2020 at 6:24 AM Piotr Szuberski > > <piotr.szuber...@polidea.com> > > wrote: > > > > > Beam has quite old Solr dependency (5.x.y) which has been deprecated for a > > > long time. > > > > > > Solr dependency has recently been updated to 8.6.y, but there is a > > > question which versions should be supported? > > > > > > Are there users using versions older than 7.x.y? > > > > > >
