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 g
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 questio
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 p
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 cou
