Re: Which Solr versions should be supported by Beam
Another response from Solr devlist: Based on the questions that we've seen over the past month on this list, there are still users with Solr on 6, 7, and 8. I suspect there are still Solr 5 users out there too, although they don't appear to be asking for help - likely they are in set it and forget it mode. Solr 7 may not be officially deprecated on our site, but it's pretty old at this point and we're not doing any development on it outside of mybe a very high profile security fix. Even then, we might acknowledge it and recommend users update to 8.x anyway. The index files generated by Lucene and consumed by Solr are backwards compatible up to one major version. Some of the API remains compatible, a client issuing simple queries to Solr 5 would probably work fine even against Solr 9 when it comes out eventually. A client doing admin operations will be less certain. I don't know enough about Beam to tell you where on the spectrum your use will fall.
Re: Which Solr versions should be supported by Beam
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 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 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 > > > > 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? > > > > > >
Re: Which Solr versions should be supported by Beam
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 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 > 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? > > >
Re: Which Solr versions should be supported by Beam
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 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? >
