On 1/4/2016 1:55 PM, Jack Krupansky 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 said much the same thing on SOLR-8475 a short time ago. I'm all for creating branch_6x in the very near future and looking forward to the actual release a few months after that. The CHANGES.txt for 5.5 looks very extensive for both solr and lucene, so I believe that we should probably get 5.5 out the door first. > 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. That is what we aim for. I personally am not opposed to making very minor changes to my custom code when a new minor version comes out, but if that's avoidable, everybody wins. Any time I write code that uses the Solr API (separate from the SolrJ API), I presume ahead of time that my plugin jar may not work when I upgrade Solr. This is probably paranoia, but because I recompile my plugin anytime I upgrade, I know that any problems I encounter are likely due to my own mistakes. > Whether the Lucene guys have the same concerns as the Solr guys is an > interesting question. A "user" of Lucene is typically a developer, someone who presumably knows how to fix problems created by API changes. If their code stops working when they upgrade a dependency like Lucene, they can adapt. Also, because of the very nature of the project, I think that Lucene devs are very good about indicating which Lucene APIs are expert/internal and subject to change. Lucene internals are very complex, but we have some incredibly smart people here who know them very well, and they know which APIs are unlikely to be found in typical user programs. A typical Solr user is not a developer, and just wants everything to work, potentially with custom code that they cannot change or recompile. I don't think the Solr devs are less intelligent than the Lucene devs ... but because Solr is primarily an application rather than an API, I don't think that there is as much effort in the Solr code to indicate which APIs should be considered expert/internal. I know from experience that third-party Solr plugins are sometimes extremely version-specific, so the goal of custom code working with a new minor version is not always achieved. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
