+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

Reply via email to