On 12/6/2011 2:06 PM, Erik Hatcher wrote:
I think the best thing that you could do here would be to lock in a version of Lucene (all the Lucene libraries) that you use with SolrCloud. Certainly not out of the realm of possibilities of some upcoming SolrCloud capability that requires some upgrading of Lucene though, but you may be set for a little while at least.
I have no weight with the Lucene project, especially because I know very little of its internals.
If the code that handles each new index format were also able to read the index format that preceded it, one could incrementally step forward from revision to revision within trunk, running an optimize (forcedMerge?) at each version to upgrade the index format.
On the other hand, any reasonable production installation will consist of redundant hardware, and if someone is already willing to take the risk of running trunk, it can be argued that they should also be prepared to take down one of their redundant systems and use it to reindex on an upgraded version, then run parallel update programs on both versions. This is what I did when upgrading from 1.4.1 to 3.2, because of the javabin difficulties. Once I had that system in place, I also used it for the minor steps to 3.4 and 3.5.
I'd hope for the former, but if that's not going to happen, there is the latter.
Thanks, Shawn
