lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject release & migration plan
Date Mon, 12 Jul 2004 17:09:36 GMT
I think perhaps it is time to make some incompatible changes to Lucene's 
API.  There are a number of places where it is showing its age.  I'd 
like to try to make as many API changes at once as is possible, so that 
folks only have to port application code once.

I propose we do this as follows:

1. Make a 1.9 release which has all the new APIs and deprecates all the 
outdated APIs.  Existing applications should compile and run fine, but 
with lots of deprecation warnings.

2. Make a 2.0 release which removes all deprecated code.

Thus 1.9 would be a migration release.  Before an application is moved 
to 2.0, folks should first make sure that it compiles against 1.9 
without deprecation warnings.  Once it does then it should move to 2.0 
without incident.

Does this sound like a good plan?

What changes would I like to see in the API?  Here are a few candidates:

1. Replace Field factory methods (Field.Text, Field.Keyword, etc.) with 
a few methods that use type-safe enumerations, as described in:

2. Similarly, replace BooleanQuery.add() with a type-safe enumeration, 
also as described in:

3. Replace public IndexWriter fields (mergeFactor, minMergeDocs, etc.) 
with get/set accessors.  Also, minMergeDocs should be renamed 

4. Rename PhrasePrefixQuery to be something like MultiPhraseQuery.  Also 
make MultipleTermPositions a private nested class of this, as this is 
the only place MultipleTermPositions is used.

5. Rename InputSteam to IndexInput and OutputStream to IndexOutput. 
Also make both of these interfaces and add BufferedIndexInput and 
BufferedIndexOutput as the implementation used by FSDirectory, 
RAMDirectory, etc.  This would permit unbuffered and native 
implementations (e.g., that use mmap) that could potentially speed 
things considerably.

6. Replace DateField with something that formats dates suitably for 

7. Move language-specific analyzers into separate downloads?

8. Add support for span queries to query parser?

Do you have other candidates?


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

View raw message