I propose that I execute at least part of this plan Thursday night for main branch, backport to 10 straight away: * remove BaseHttpSolrClient, the deprecated base class of HttpSolrClient * rename HttpSolrClient to HttpApacheSolrClient * rename CloudLegacySolrClient to CloudApacheSolrClient * rename LBHttpSolrClient to LbApacheSolrClient (lowercase 'b') * rename ConcurrentUpdateSolrClient to ConcurrentUpdateApacheSolrClient * rename HttpClusterStateProvider to HttpApacheClusterStateProvider
I will do that purely mechanically by IntelliJ IDEA. The PR will be no fun to look at and will have no other changes whatsoever to review. Ref guide, CHANGES.txt, can be in another PR (commit) so that it's not lost in a sea of wrote changes. The above only changes deprecated clients. "HttpSolrClient" (a great-name) won't exist but let's add afterwards/soon. The rest of the renames can be in a follow-up, that I'll announce on this thread. I could do likewise for the other clients. I'm aware of work James is doing so I don't want to disturb that at the moment. If I get a couple +1 and no dissent, I'll proceed. On Mon, Sep 29, 2025 at 1:40 PM James Dyer <[email protected]> wrote: > I agree with all the "HTTP" renames proposed here. I do want to point > out that with the Load Balanced client, we opted to make > `LBHttp2SolrClient` work with both the Jetty and JDK client variants. > (see https://github.com/apache/solr/pull/2828) My hope is that the > same can be done for both `CloudSolrClient` and > `ClusterStateProvider`. For these more-advanced clients that really > just layer on more functionality, we should try not have a bespoke > variant for each underlying base client implementation. With that in > mind, the less-specific the naming the better. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
