On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
