On Aug 23, 2009, at 2:06 PM, Simon Willnauer wrote:

My two cents. I think the contract of the 3.0 release is that it is a drop in replacement for the 2.9 release but requires Java 1.5. I expect to compile against Lucene 2.9 using Java 1.4, removing deprecations. And then go to Lucene 3.0 changing the compiler to Java 1.5 but making no code changes.

To that end, any introduction of Java 1.5 into the end-user/non-expert/ non-experimental/non-contrib API needs to work with existing code as is. It may require the user to compile with lax permissions using Java 1.5 and run with Java 1.5.

Requiring Java 1.5 can be as easy as using a Java 1.5 feature internally, in the expert or experimental APIs, and classes that are not part of the backward compatibility contract (e.g. utility classes).

I don't think there should be any effort to maintain Java 1.4 compatibility, but I also think changes should be made only where it makes sense, giving a clear advantage (performance, maintainability, ....). If that results in 1.4 compatibility it is a temporary benefit not guaranteed during the 3.x series.

I agree with previous threads that there is both a blessing and a curse with Lucene's backward compatibility release policy. My biggest gripe is the evolution toward bad class names. I would like to see a 4.0 release dedicated to fixing the name/api problems and making the API of Lucene be what it should have been for a 3.0 release. I'd also suggest that repackaging, suggested in a prior thread, be tackled also. This could follow a 3.0 release quickly.