lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
Date Mon, 30 Jul 2007 16:48:09 GMT

On Jul 30, 2007, at 8:18 AM, DM Smith wrote:

> +1 from me, too. Not because I have a vote or that I am for going  
> to 1.5, but because it is inevitable and this is a well thought  
> out, fine plan. (excepting the aggressive timeline that has been  
> hashed out already in this thread)
> I'd like to point out that there is a consequence of this plan and  
> how Lucene has done things in the past.
> At 1.9 it was fully compatible with 1.4.3, with deprecations. 2.0  
> mostly had deprecations removed and a few bug fixes. Then the 2.x  
> series has been backwardly compatible but not with 1.x (except  
> being able to read prior indexes, perhaps a few other things.).
> If we continue that same pattern, then there will be no 1.5  
> features in 2.9. (Otherwise it won't compile under 1.4). Thus, 3.0  
> will have a 1.4.2 compatible interface. And except for new classes,  
> new methods and compile equivalent features (such as Enums), 1.5  
> features won't appear in the 3.x series API.

Yes, this is a slight variation from the 1.9 -> 2.0 migration.  I  
think the plan is to switch to 1.5 for compilation for 3.0-dev and  
then we will be immediately open for accepting 1.5 patches.  In fact,  
if someone submitted a patch that converted all collections to  
generics, I would be in favor of accepting it with all the usual  
caveats.  I don't see any other way around, as I don't think the  
intent is to say that 3.x contains no 1.5 features other than it  
compiles using JDK 1.5.

> I think it is very important to preserve the Lucene API where  
> possible and reasonable, not changing it without gain. Given that  
> this has been the practice, I don't think it is an issue.

I agree.  I think method names, etc. will stay the same, but we will  
start adding Generics and Enums where appropriate and new code can be  
all 1.5.  For instance, though, the Field declaration parameters are  
a prime place for Enums.  So, the move would be to add in the new  
Enums and deprecate the old Field.Index and Field.Store static ints.   
Thus, they would not go away until 4.x (wow, that is weird to say)

Does that seem reasonable?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message