The fact that users can write plugins and the plugins can access almost any public methods make it extremely hard to remain backward compatible. However , we should not hesitate to break backcompat (if required). Users have the choice of sticking to the old version and rewrite his plugins using the nw API. However public/REST APIs should not break backcompat in a minor verion
On Mon, Jan 4, 2016 at 10:17 PM, Anshum Gupta <[email protected]> wrote: > Yes, I'm looking at a long term consensus on issues like SOLR-8475. > > It would make it possible to improve the code without having to wait until a > major version is released. > > On Mon, Jan 4, 2016 at 10:13 PM, Yonik Seeley <[email protected]> wrote: >> >> On Mon, Jan 4, 2016 at 11:35 AM, Jack Krupansky >> <[email protected]> wrote: >> > Probably back-compat for the Solr plugin API as well - people have >> > custom >> > plugins that should work without a needed refactor. That would include >> > custom tokenizers, token filters, char filters, query parsers, request >> > handlers. >> > >> > That probably implies back-compat for the major APIs for Solr core as >> > well - >> > the code that plugins need to call. >> >> That reflects our current policy (i.e. things like >> SolrIndexSearcher/QueryCommand/QueryResult would be covered). >> >> I think Anshum is looking for something that would allow the refactors >> in this issue to be committed to 5.5 >> https://issues.apache.org/jira/browse/SOLR-8475 >> >> -Yonik >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Anshum Gupta -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
