On Jan 12, 2008, at 6:35 PM, Chris Hostetter wrote:
: Hmm, actually this is probably too restrictive. But maybe we could
say
: that Lucene 3.0 doesn't have to be able to read indexes built with
: versions older than 2.0?
that is in fact the position that lucene has had since as long as
i've ben
involved with it...
http://wiki.apache.org/lucene-java/BackwardsCompatibility
File formats are back-compatible between major versions. Version X.N
should be able to read indexes generated by any version after and
including version X-1.0, but may-or-may-not be able to read indexes
generated by version X-2.N.
3.X must be able to read file created by 2.Y (where X and Y can be any
number)
If I remember right, the file format changed in 2.1, such that 2.0
could not read a 2.1 index.
I seem to recall that 2.0 was 1.9 with the deprecations removed and
perhaps some minor changes.
I think we are going to need to do similar approach to change the file
formats but especially to go to Java 5.
Release 3.0 will be the first to require Java 5. But we can't do it as
we did before, where the new api was introduced in the x.9 release,
with the old marked as deprecated. To do so would make 2.9 not be a
drop in replacement for 2.4.
I'd like to recommend that 3.0 contain the new Java 5 API changes and
what it replaces be marked deprecated. 3.0 would also remove what was
deprecated in 2.9. Then in 3.1 we remove the deprecations.
While I was very vocal against going to Java 5, I'm very agreeable
with the change now. But, I'd like to see it be done in a consistent,
deliberate and well thought out manner. And I'd like to help out where
I can.
I still hope to "back port" any changes to Java 1.4.2, but with how
well the 2.x series performs, I am much less inclined to do so. Lucene
2.x is most excellent!!
-- DM Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
