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 <[email protected]> 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 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 <[email protected]> wrote: > >> On Mon, Jan 4, 2016 at 12:07 PM, Alexandre Rafalovitch >> <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
