Solr plugin story is muddy enough as it is. Plugins are hard to find, share. So, in my eyes, breaking them is not a big effect as if we had a big active registry.
I guess this is opening the brackets, not the original issue. Feel free to treat that as an invitation for a separate discussion, in an its own thread at any point. Regards, Alex. ---- Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 5 January 2016 at 00:03, Noble Paul <noble.p...@gmail.com> wrote: > 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 <ans...@anshumgupta.net> 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 <ysee...@gmail.com> wrote: >>> >>> On Mon, Jan 4, 2016 at 11:35 AM, Jack Krupansky >>> <jack.krupan...@gmail.com> 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: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> >> >> >> -- >> Anshum Gupta > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
