lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: Potential bug in StandardTokenizerImpl
Date Thu, 29 Nov 2007 12:18:56 GMT
Yeah, one of the things that I am not thrilled about our model is that  
it essentially means we can only make these kinds of changes on 3.0- 
dev (i.e. before releasing 3.0), not a big deal in theory, but as  
evidenced by Hoss's history on this particular item, it has been  
around for a long time.  So, either we need to get better about  
marking things for that window right before a major release and fixing  
them at that time or we need some other way of addressing it.

Is there no way in JFlex to set a flag that defaults to the current  
way, else if set it does the proper thing?  And then we could  
deprecate the old way?

-Grant

On Nov 29, 2007, at 12:57 AM, Shai Erera wrote:

> I agree that being backward compatible is important. But ... I also  
> work at
> a company that delivers search solutions to many customers. Sometimes,
> customers are being told that a specific fix will require them to  
> rebuild
> their indexes. Customers can then choose whether to install the fix  
> or not.
> However, from your statement below I gather that once Lucene 3.0  
> will be
> out, we won't have to be backward compatible, and that fix can go  
> into that
> release ... if I'm right, then someone can mark that issue for 3.0  
> and not
> 2.3 (I'm not sure I have the permissions to do so).
>
> Isn't there a way to include a fix that you can choose whether to  
> install or
> not? For example, I may want to download 2.3 (when it's out) and  
> apply this
> patch only. I'm sure there's a way to do it. If there is, we could  
> publish
> this as official in 3.0 and patch available for 2.3 (I fixed it only  
> in
> jflex, but can easily produce a patch for .jj file, so if will fix
> 2.2version as well).
>
> My only concern is that this patch will get lost if we don't mark it  
> for any
> release ...
>
> Shai
>
> On Nov 28, 2007 9:18 PM, Chris Hostetter <hossman_lucene@fucit.org>  
> wrote:
>
>>
>> : Thanks to Shai Erera for traslating the discussion into the  
>> developers'
>> : list. I am surprised about Chris Hostetter's response, as this  
>> issue was
>>
>> to clarify: i'm not saying that the current behavior is ideal, or  
>> even
>> correct -- i'm saying the current behavior is the current behavior,  
>> and
>> changing it could easily break existing indexes -- something that the
>> Lucene upgrade contract does not allow...
>>
>> http://wiki.apache.org/lucene-java/BackwardsCompatibility
>>
>> specificly: if someone built an index with 2.2, that index needs to  
>> work
>> when queried by an app running 2.3 .. if we change the  
>> StandardTokenizer
>> to treat this differnetly, that won't work.
>>
>> In some cases, being backwards compatible is more important then  
>> being
>> "correct" ... i'm not 100% certain that this is one of those cases,  
>> i'm
>> just pointing out that there is more to this issue then just a one  
>> line
>> patch to some code.
>>
>>
>> -Hoss
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
>
> -- 
> Regards,
>
> Shai Erera

--------------------------
Grant Ingersoll
http://lucene.grantingersoll.com

Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ




---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message