On Tue, 20 Jul 2010, Thomas Koch wrote:
Porting your stuff to Lucene 3.0 is recommended...
[Thomas Koch] That's what I'm supposed to do next: port our PyLucene code to
some "up-to-date" release - our codebase is still on PyLucene 2.6 and I
expect it to break with the 3.x release ...
With that in mind: is it still worth looking at/supporting PyLucene 2.x or
do you suggest to switch to 3.x directly?
PyLucene is coordinating its releases and support with Lucene Java. As long
as Lucene Java is making 2.x releases, I see no reason to not do so as well
for PyLucene 2.x.
I understand that Lucene 2.x is Java1.4 compatible and Lucene 3.x makes use
of Java5 generics. Is it still API compatible or a complete new branch?
Lucene Java has a policy to only break API compatibility when making major
releases as when going from 2.x to 3.x. They sure did so for 3.0 and the
Lucene Java 2.9.x release series is the one where both APIs are supported
but with the obsolete 2.x APIs marked as deprecated.
In Lucene Java 3.0, they've removed all the APIs thus deprecated in 2.x. The
point they're making, and rightly so, is that before upgrading to 3.x, be
sure that you're not using any deprecated APIs by using the java compiler
deprecation warnings as canari. Only then should you upgrade to 3.x.
I realize that PyLucene doesn't make that easy because it doesn't warn about
deprecated API use.
One thing I could add to JCC is a command line flag to _not_ wrap any
deprecated APIs. With that applied to PyLucene, one could then find all
errors they'd be hitting when upgrading to 3.x. That being said, I don't see
the difference between this and just upgrading to 3.x and looking for the
very same errors since, by definition, 3.0 == 2.9 - deprecations. This
explains why I haven't implemented this feature so far.
Andi..
Regards
Thomas
