On Tue, May 19, 2009 at 4:33 PM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Tue, May 19, 2009 at 2:27 PM, Yonik Seeley > <yo...@lucidimagination.com> wrote: >> On Tue, May 19, 2009 at 2:04 PM, Michael McCandless >> <luc...@mikemccandless.com> wrote: >>> On Tue, May 19, 2009 at 9:34 AM, Yonik Seeley >>> <yo...@lucidimagination.com> wrote: >>> >>>> Selecting backward compatibility vs latest and greatest could be done >>>> w/o Settings (a simple static int containing the version number to act >>>> like). It seems like the Settings debate should be based on it's own >>>> merits. >>> >>> But isn't a static int too restrictive? That means all usage of >>> Lucene from within this JRE must match that version? >> >> Isn't that currently the case though? One Lucene jar, one behavior. > > Right, that's exactly why I want to fix it (only one behavior allowed > and so for all of 2.* we must match the 2.0 behavior).
I meant one jar per per-jvm gives you one behavior (as is the case now). But by setting a static actsAs version number, you could get a 2.* jar to behave as if it were 2.0, even as behaviors evolve. I'm not saying that a Settings class is a bad idea - it's just bigger than the issue of handling strict back compatibility and evolution at the same time, which could possibly be done in a much simpler manner w/o any API changes. Of course if we decided to go with a Settings class, it would render a static actsAs redundant. -Yonik --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
