Grant Ingersoll wrote:
I am wondering what the motivation is for being forward compatible to 2.0. Is the only change from 1.9 to 2.0 going to be the removal of deprecated items?
Pretty much, yes.
Are we going to be preventing ourselves from making broader structural changes? My understanding of a major release is that it allows you to make large scale changes, if needed, that may break existing dependencies.
We're using the major version number to denote API compatibility. Index formats can change (back-compatibly) and features can be added within a major release, but the API should not change incompatibly. When we do need to change the API compatibly we try to do it by introducing new methods and classes and deprecating old methods an classes.
Lucene has a large install base. A little effort towards back-compatibility on our part saves folks a lot of effort.
For instance, I am working on a lazy field loader patch (so that large fields aren't loaded just b/c the document is loaded) and also am looking into the possibility of updating single fields on a document. The first change takes the Field class and makes it an interface which has two implementations, one that is lazy and the current one. Granted, I haven't submitted the patch yet, but if this is something that people are interested in, then it would make 2.0 not be compatible with 1.9.
This sounds like it could be done with back-compatible APIs. The new interface could be named Fieldable or something rather than field.
From http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard, item #11 is almost certainly going to break things, as well, if someone takes it on.
I hope this can be done back-compatibly both for the API and the index format. If it cannot be reasonably done that way then we'll deal with that then.
Doug --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
