Call me lazy if you will, but I don't want us increasing our Solr maintenance burden further by adding deprecated annotations and shims for moving classes *on a major release*. Touching 9.x over the matter is not actionable to a user. Users are expecting to have to make changes on a major release!
I would like to take this conversation as an opportunity to bring up the package org.apache.solr.client.solrj and some things I think do *not* belong there, and some things that I think *do*. Please go look for yourself. This is the root package for most of SolrJ, aside from "common". There are many sub-packages. Consequently, I think we should be thoughtful/conservative on what goes in this package. Move out: * JacksonContentWriter should go to the "request" sub-package (or "request.json"), where other ContentWriters are. * JacksonDataBindResponseParser should go somewhere; perhaps "impl" since the other ResponseParsers are there, albeit I detest the organizational idea of an "impl" package. If not there, the "response" (or "response.json") package would otherwise be an obvious home by its name. * InputStreamResponse should go to the "response" sub-package. Move in: from "impl" * HttpSolrClient (the new base abstraction, not the old Apache HttpClient using one). I have a PR doing this: https://github.com/apache/solr/pull/3829 * CloudSolrClient On Tue, Nov 4, 2025 at 7:44 PM Jan Høydahl <[email protected]> wrote: > > Is that what you mean to suggest in the case of 1:1 method renames with > no > > functionality change? Such a change does break compilation, but it's a > > trivial fix (if properly documented). I think it's understood through > this > > entire conversation that back compat breaks are a "major version only" > > prospect, but the question is where to draw the line on deprecation vs > > simply changing it at the major version boundary. > > It is more work to provide a rename or package move if you also need to > produce shims for the old behavior to work. And in SolrJ for v10 we even > re-use a previous class name for a differenet purpose, so for such a change > to work with deprecation we'd need to place the new impl in a different > package. No wonder some frameworks include version in the package name. > > So in 90% of the cases, yes, we should first implement and release the new > and better API, then deprecate the old and finally remove in next major. > For Tika I first introduced the new "tikaserver" backend before > deprecating the "local" backend. > But our project have several examples of us deprecating features without a > replacement (DIH, CDCR, Autoscaling). Sometimes that is the only option if > we discourage use of the old impl for any production use. > > Jan > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
