: If I remember right, the file format changed in 2.1, such that 2.0 could not : read a 2.1 index.
that is totally within the bounds of the compatibility statement... http://wiki.apache.org/lucene-java/BackwardsCompatibility >>Note that older releases are never guaranteed to be able to read indexes >>generated by newer releases. When this is attempted, a predictable error >>should be generated. : 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. there's no reason why new APIs can't be introduced in 2.9, new APIs were introduced in 1.9 and it was still a drop in replacemend for 1.4. The only hitch that makes 3.0/2.9 differnet then 2.0/1.9 is that since we're going to start allowing JDK1.5 features in 3.0, any new APIs that want to use 1.5 *syntax* features have to wait until 3.0. This admittedly is where some discussion should probably happen, because this might mean that because of some design decisions about what some new API should look like, 2.9 gets some deprecation messages warning people that a method won't be supported in 3.0, without the replacement method existing in 2.9 (because it requires generics or some new standard library class that isn't in 1.4) making it imposisble for some apps to compile against 2.9 without getting deprecation warnings. but personally i don't think that's not the end of the world, particularly if we make it clear that 2.9 is a transitional release. But as i say: some discussion should probably happen. Incidently, here is the summary of the discussion about the 2.4,2.9,3.0/1.5 plan ... http://wiki.apache.org/lucene-java/Java_1%2e5_Migration (the details of how deprecations and new 1.5 APIs and deprecations in 2.9 should be dealt with is admittedly a little fuzzy in the wiki, i can't remember if they were fleshed out in any more depth in on the mailing list, and i don't have the energy to re-read it all now) : 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. FWIW: This would violate the compatibility requirements, since code that compiles against 3.0 (with deprecation warnings) wouldn't compile against 3.1 -- but then again: there has been some mention of revisting the entire back compatibility commitments of Lucene, and now certainly seems like the time to discuss that before too much work is done in any particular direction in an attempt to "head towards" 2.9/3.0. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
