Anshum -
Interesting timing in bringing this up. I’ve just been bitten by the
ShardHandler API change from https://issues.apache.org/jira/browse/SOLR-7714
<https://issues.apache.org/jira/browse/SOLR-7714> - I’m working on adapting
some code from
https://github.com/LucidWorks/query-autofiltering-component/tree/master/solr5.x
<https://github.com/LucidWorks/query-autofiltering-component/tree/master/solr5.x>
which was using Solr 5.1 API and now it breaks. I’m in the midst of adapting
the build and code, so I’ve locally gotten past the change that broke this API
usage:
https://github.com/LucidWorks/query-autofiltering-component/blob/master/solr5.x/src/main/java/org/apache/solr/handler/component/QueryAutoFilteringComponent.java#L807
<https://github.com/LucidWorks/query-autofiltering-component/blob/master/solr5.x/src/main/java/org/apache/solr/handler/component/QueryAutoFilteringComponent.java#L807>
where s/checkDistributed/prepDistributed/ was required. That method name
change was probably best on trunk-only? [though, maybe there’s other ways to
do what that QueryAutoFilteringComponent should be doing in distributed mode,
which I’m looking into as well]
Erik
> On Jan 4, 2016, at 11:27 AM, Anshum Gupta <[email protected]> wrote:
>
> Hi,
>
> I was looking at refactoring code in Solr and it gets really tricky and
> confusing in terms of what level of back-compat needs to be maintained.
> Ideally, we should only maintain back-compat at the REST API level. We may
> annotate a few really important Java APIs where we're guarantee back-compat
> across minor versions, but we shouldn't certainly be doing that across the
> board.
>
> Thoughts?
>
> P.S: I hope this doesn't spin-off into something I fear :)
>
> --
> Anshum Gupta
