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