I think the goal/standard with SolrJ backcompat (as I understood it) is "drop-in replacement". In theory, a user should be able to upgrade their SolrJ within the same major version and expect everything to still compile, unless they're using a "lucene.experimental" tagged class. So if the question is "what is the policy today", I think the answer is "strict compile compatibility".
But we do make exceptions to that periodically; SOLR-16781 for instance makes a big (but intentional) backcompat break in Solr 9.8. AFAIK there aren't particular rules-of-thumb for what deserves an exception, it's just a "use your best judgement" thing. Ideally exceptions would be called out in JIRA so folks can weigh in. Best, Jason On Wed, Mar 19, 2025 at 9:05 PM Mike Drob <md...@mdrob.com> wrote: > > If you compare the results from > https://github.com/search?q=%22new+RequestWriter%28%29%22+language%3AJava+path%3Aorg%2Fapache%2Fsolr&type=code&ref=advsearch > (294) and > https://github.com/search?q=%22new+RequestWriter%28%29%22+language%3AJava&type=code&ref=advsearch > (307) that suggests there are 13 places on GitHub where this gets called > outside of our own code. > > I think that's a good indicator of how much you should accommodate. > > Mike > > On Wed, Mar 19, 2025 at 7:53 PM David Smiley <dsmi...@apache.org> wrote: > > > Looking to get more visibility on backwards compatibility for SolrJ: > > > > https://issues.apache.org/jira/browse/SOLR-17518?focusedCommentId=17935379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17935379 > > > > Up until but not including SolrJ 9.9 (not released yet), a user could > > create a new RequestWriter() to write a request to Solr in XML (HTTP > > POST). In general users don't specify this; the default is "javabin", > > which is much more efficient. The change in 9.9 is that new > > RequestWriter() won't work at all, as it's abstract; new XMLRequestWriter() > > should be used. Of course it ought to have been this way all along; better > > late than never. > > > > Is compatibility here something we care to uphold? I tend to think so > > because it's a major component. A simple revert and adding a dummy > > subclass called XMLRequestWriter would be compatible and an onramp to > > compatibility with SolrJ 10. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org