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:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08479.html
2. Similarly, replace BooleanQuery.add() with a type-safe enumeration, also as described in:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08479.html
3. Replace public IndexWriter fields (mergeFactor, minMergeDocs, etc.) with get/set accessors. Also, minMergeDocs should be renamed maxBufferedDocs.
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 RangeQuery.
7. Move language-specific analyzers into separate downloads?
8. Add support for span queries to query parser?
Do you have other candidates?
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
