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] > >
