Thanks for your inputs on this. I wasn't aware of such a strict requirement for backward compatibility. Here, there is no good reason to break compilation compatibility between the two versions. The goal was just to make the code cleaner. While it makes sense in main, I understand this should not go to the 9x branch.
I will open a PR soon to bring back compilation compatibility. Le ven. 21 mars 2025 à 12:41, Jason Gerlowski <gerlowsk...@gmail.com> a écrit : > 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 > > > >
