lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Chanan <>
Subject Re: Breaking Java back-compat in Solr
Date Mon, 04 Jan 2016 21:59:41 GMT
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
the annotation.  It doesn't solve the policy issue of which annotation to
use for a given class, of course.

On Mon, Jan 4, 2016 at 12:55 PM, Jack Krupansky <>

> 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 dot releases?
> Anybody object to a Solr 6.0 in June or thereabouts? Would the folks in
> Elasticsearch land object to a Lucene 6.0 release in that timeframe (if not
> sooner!)?
> I'm +1 for saying that dot releases be limited to "no surprises", easy
> upgrades, with no app/custom code changes for the external and general
> internal APIs, but under the condition that a major release is never more
> than a year away. In any case, make a commitment to users that they can
> always safely and painlessly upgrade from x.y to x.z without code changes.
> Sure, minor and even major enhancements can occur in dot releases - to the
> extent that they "drop in" without introducing compatibility issues, with
> compatibility defined as back-compat with the Lucene index, the HTTP API,
> the Solr plugin API and any general core interfaces that reasonable plugins
> might use.
> And if this policy puts greater pressure on getting an earlier 6.0
> release, so be it. +1 for that.
> Whether the Lucene guys have the same concerns as the Solr guys is an
> interesting question.
> -- Jack Krupansky
> On Mon, Jan 4, 2016 at 12:30 PM, Yonik Seeley <> wrote:
>> 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 the issue here (a custom
>> qparser, search component, update processor).
>> The basic question is: should people using these be able to upgrade
>> from 5.4 to 5.5 without having to change and recompile their code?
>> -Yonik
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

View raw message