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). We've come full circle ;) Ie the status quo is bad since we are forced to hurt new users in order to preserve back compat, when presumably new users outnumber back-compat users who are upgrading. I'd love to default no-scoring when sorting by field, in 2.9, but I can't, unless we had something along the lines of *Settings, or "specify the version compat you require" when creating each class. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
