On Fri, May 22, 2009 at 11:53:02AM -0400, Michael McCandless wrote:
> 1. If we deprecate an API in the 2.1 release, we can remove it in
> the next minor release (2.2).
>
> 2. JAR drop-in-ability is only guaranteed on point releases (2.4.1
> is a drop-in replacement to 2.4.0). When switching to a new
> minor release (2.1 -> 2.2) likely you'll need to recompile.
> 4. [Maybe?] Allow certain limited changes that will require source
> code changes in your app on upgrading to a new minor release:
> adding a new method to an interface, adding a new abstract method
> to an abstract class, renaming of deprecated methods.
These make sense to me. Catastrophic failure at compile time is vastly
easier to deal with than subtle failure at run time.
> 3. Default settings can change, but if the change is big enough (and
> certainly if it will impact what's indexed or how searches find
> docs/do scoring), we add a required "actsAsVersion" arg to the
> ctor of the affected class. New users get the latest & greatest,
> and upgraded users keep their old defaults.
I still like per-class settings classes. For instance, an IndexWriterSettings
class which allows you to hide away all the tweaky stuff that's cluttering up
the IndexWriter API.
IndexWriterSettings settings = new IndexWriterSettings("3.1");
IndexWriter writer = new IndexWriter("path/to/index", analyzer, settings);
I also think that the argument should be optional rather than mandatory, and
that defaults should remain stable between major releases. In other words, to
take advantage of improved defaults, you need to ask for them -- but new users
don't have to think about such things during the initial learning phase.
This approach is reasonably close to how Architecture and IndexManager are
used to hide away settings for the KS/Lucy Indexer class.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
