+1 on the Analyzers split, But would like to point out that it's not very different than having a non final static "version" field. Just a much better solution as you keep your code manageable.
2010/4/15 Grant Ingersoll <gsing...@apache.org>: > > On Apr 15, 2010, at 4:21 PM, Shai Erera wrote: > >> +1 on the Analyzers as well. >> >> Earwin, I think I don't mind if we introduce migrate() elsewhere rather than >> on IW. What I meant to say is that if we stick w/ index format back-compat >> and ongoing migration, then such a method would be useful on IW for >> customers to call to ensure they're on the latest version. >> But if the majority here agree w/ a standalone tool, then I'm ok if it sits >> elsewhere. >> >> Grant, I'm all for 'just doing it and see what happens'. But I think we need >> to at least decide what we're going to do so it's clear to everyone. Because >> I'd like to know if I'm about to propose an index format change, whether I >> need to build migration tool or not. Actually, I'd like to know if people >> like Robert (basically those who have no problem to reindex and don't >> understand the fuss around it) will want to change the index format - can I >> count on them to be asked to provide such tool? That's to me a policy we >> should decide on ... whatever the consequences. > > As I said, we should strive for index compatibility, but even in the past, we > said we did, but the implications weren't always clear. I think index > compatibility is very important. I've seen plenty of times where reindexing > is not possible. But even then, you still have the option of testing to find > out whether you can update or not. If you can't update, then don't until you > can figure out how to do it. FWIW, I think our approach is much more > proactive than "see what happens". I'd argue, that in the past, our approach > was "see what happens", only the "seeing" didn't happen until after the > release! > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
