lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yonik Seeley <ysee...@gmail.com>
Subject Re: Breaking Java back-compat in Solr
Date Wed, 06 Jan 2016 15:43:09 GMT
On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta <anshum@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.

I think this actually represents what our current policy already is.
The sticking point is perhaps "Strive to maintain" is changing
definition to become much more lenient, to the point of being
meaningless.

Let's look at the issue that spawned this thread:
https://issues.apache.org/jira/browse/SOLR-8475  (Some refactoring to
SolrIndexSearcher)

The issue is if QueryCommand and QueryResult should be moved out of
SolrIndexSearcher in 5.x (essentially a rename), or of that rename
should only be in 6.0.  If one's desire for a class rename (of classes
that are likely to be used by plugins) overrides #2, I'd argue that
means we essentially have no #2 at all.  Or perhaps I'm not grasping
why it's really that important to rename those classes.

Regarding annotations:
Multiple people have suggested annotating classes that should remain
back compat.  If we were to do this, wouldn't we want those
annotations to cover the classes in question
(SolrIndexSearcher,QueryCommand,QueryResult)?  If not, what would they
cover and still be useful?

-Yonik

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message