RE: Breaking Java back-compat in Solr

From: ser...@gmail.com Date: Sun, 10 Jan 2016 13:58:52 + Subject: Re: Breaking Java back-compat in Solr To: dev@lucene.apache.org I think that our Maven integration only publishes Lucene/Solr artifacts to Maven central, but I don't think the POMs actually produce the artifacts? I could

RE: Breaking Java back-compat in Solr

can you also add this to lucene pom.xml ? Martin __ From: ser...@gmail.com Date: Sun, 10 Jan 2016 07:57:26 + Subject: Re: Breaking Java back

Re: Breaking Java back-compat in Solr

07:57:26 + > Subject: Re: Breaking Java back-compat in Solr > To: dev@lucene.apache.org > > > As for SOLR-8475, I will commit it to trunk only. But I think that we > should come up w/ concrete annotations in our code, and annotate classes as > we go, to back our back-co

Re: Breaking Java back-compat in Solr

As for SOLR-8475, I will commit it to trunk only. But I think that we should come up w/ concrete annotations in our code, and annotate classes as we go, to back our back-compat policy. I propose that we add these: @solr.internal - this is internal API and will change without notice. No

Re: Breaking Java back-compat in Solr

With the talk of 6.0 coming out real soon and not waiting for new work, will this 6.0/5.x issue become moot and morph into an issue for 7.0/6.x? Settling the criteria for Solr plugin API back-compat still seems urgent, but if the SOLR-8475 work can quickly get committed to trunk for 6.0 maybe

Re: Breaking Java back-compat in Solr

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 wrote: > As I understand,

Re: Breaking Java back-compat in Solr

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

Re: Breaking Java back-compat in Solr

On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta 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. I think

Re: Breaking Java back-compat in Solr

We have never promised or delivered back compat on Java APIs beyond best effort. I agree we should stick to http APIs and solrj for stronger back compat, and simply do our best to be reasonable with the rest. Mark On Tue, Jan 5, 2016 at 2:05 AM Shai Erera wrote: > In Lucene

Re: Breaking Java back-compat in Solr

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

Re: Breaking Java back-compat in Solr

I suspect that half the issue here is that 6.0 is viewed as too far away so that any trunk-only enhancements are then seen as not having any near-term relevance. If 6.0 were targeted for sometime within the next six months, would that not take a lot out of the urgency for major/breaking changes in

Re: Breaking Java back-compat in Solr

Has there been any discussion about annotating back compat expectations universally, similar to hadoop's use of InterfaceStability? That of course only solves the first issue: "gets really tricky and confusing in terms of what level of back-compat needs to be maintained", because it's defined by

Re: Breaking Java back-compat in Solr

On 1/4/2016 1:55 PM, Jack Krupansky wrote: > I suspect that half the issue here is that 6.0 is viewed as too far > away so that any trunk-only enhancements are then seen as not having > any near-term relevance. If 6.0 were targeted for sometime within the > next six months, would that not take a

Re: Breaking Java back-compat in Solr

Great topic Anshum. I’ve been frustrated with the back-compat situation since Lucene/Solr 5 as a maintainer of my “SolrTextTagger”. One version of the plugin supports 4.3 thru the end of the 4x line, whereas on the 5x side I’ve needed 3 versions already (5.0-5,1, 5.2, 5.3+)! Sometimes on the

Re: Breaking Java back-compat in Solr

In Lucene there are three types of public APIs: "public stable": not annotated and for them we try to maintain backward compatibility across minor releases "public experimental": annotated with @lucene.experimental. If possible, back-compat is maintained, but otherwise you can expect them to

Re: Breaking Java back-compat in Solr

I would say, SolrJ and REST APIs MUST BE backward compatible between minor versions. The question is about the internal java APIs. It is impossible to get 100% right on these things. If we can start annotating classes/methods and let users suggest stuff then we should be in a reasonably good

Re: Breaking Java back-compat in Solr

Thanks David, I agree with what you've suggested but the bigger question here again is *which* files do we guarantee back-compat for. I suggest we guarantee back-compat for SolrJ and REST APIs. For everything else i.e. Java APIs, we should try and maintain back-compat but there shouldn't be a

Re: Breaking Java back-compat in Solr

Add in major components, such as SearchComponent, IpdateProcessor, etc, they need to be considered stable. On Tue, Jan 5, 2016, at 05:49 AM, Anshum Gupta wrote: > Thanks David, > > I agree with what you've suggested but the bigger question here again > is *which* files a we guarantee back-compat

Re: Breaking Java back-compat in Solr

On Mon, Jan 4, 2016 at 12:07 PM, Alexandre Rafalovitch wrote: > 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 think private plugins / components are more

Re: Breaking Java back-compat in Solr

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 - I’m working on adapting some code from

Re: Breaking Java back-compat in Solr

IMHO It's OK if the user has to go through recompile/modify their custom component as long as it is obvious as to what is changed and we give clear documentation on how to upgrade On Mon, Jan 4, 2016 at 11:00 PM, Yonik Seeley wrote: > On Mon, Jan 4, 2016 at 12:07 PM, Alexandre

Re: Breaking Java back-compat in Solr

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

Re: Breaking Java back-compat in Solr

On Mon, Jan 4, 2016 at 11:35 AM, Jack Krupansky 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,

Breaking Java back-compat in Solr

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

Re: Breaking Java back-compat in Solr

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 wrote: > On Mon, Jan 4, 2016 at 11:35 AM, Jack Krupansky

Re: Breaking Java back-compat in Solr

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

Re: Breaking Java back-compat in Solr

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