Solr config and schema settings should also be considered part the outer API and require strong back-compat.
"Strive to maintain" and "simply do our best to be reasonable" certainly seem to be good approaches to plugin-related internal APIs. I would add "the benefits to users or committers or expert Solr contributers are compelling" as a requirement for breaking back-compat on any plugin-related internal API change. The problem with SOLR-8475 is that it appears to be more of an "internal code cleanup"-only refactor that doesn't offer any direct benefit to users or even expert Solr contributers. That sounds more ideal for a major release trunk change and that any backporting should be limited to maintaining plugin compatibility. At present, nothing in the description for SOLR-8475 suggests a "compelling" need to be in a dot release rather than a trunk/major release. If that is not the case, it sure more be helpful if the Jira were updated to reveal any compelling benefits beyond simply cleaning up the code. I'm not suggesting any opposition to general code cleanup that can be done for both trunk and the stable branch, but maybe at least it would make sense to separate basic code cleanup from changes that may affect plugin compatibility. If the code cleanup dramatically simplified the implementation of a new feature or leads to some decent performance improvement or significant reduction in memory use, then that would be... "compelling." I'd rather see more of a rush to get 6.0 out (and cleaned up) than a rush to clean up code in some random dot release. I'm +1 for any policy for dot release plugin API back-compat based on strive/reasonable/compelling, but I'm -1 if the motivation is simply cleanup the code at the expense of plugin compatibility and without a compelling benefit to users or Expert contributors. (Says the guy who has no binding vote in this matter.) -- Jack Krupansky On Wed, Jan 6, 2016 at 8:15 AM, Noble Paul <noble.p...@gmail.com> wrote: > Yes Anshum > HTTP APIs and SolrJ must have strong backcompat > > We should have a process to mark some internal APIs as backward > compatible using some annotation/javadoc. This will help plugin > writers > > On Wed, Jan 6, 2016 at 11:33 AM, Anshum Gupta <ans...@anshumgupta.net> > wrote: > > As I understand, seems like there's reasonable consensus that we will: > > > > 1. provide strong back-compat for for SolrJ and REST APIs > > 2. Strive to maintain but not guarantee *strong* back-compat for Java > APIs. > > > > Please correct me if I'm wrong. > > > > > > On Mon, Jan 4, 2016 at 9:57 PM, Anshum Gupta <ans...@anshumgupta.net> > 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 > > > > > > > > > > -- > > Anshum Gupta > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
