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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Shai Erera
