OK, net/net it doesn't look like we're going reach agreement on some general approach for having users of Lucene always get the best default settings.
We started with the *Settings classes, but that's really a very large project (goes far beyond managing defaults for new users). Then we went to the other end of the spectrum with a single global actsAsVersion, but sneaky spooky action at a distance bugs nixed that. We thought about storing actsAsVersion in the index, but that's too automagic (and would also lead to sneaky bugs / confusion). Finally we considered about passing in actsAsVersion to those classes that need to change their defaults, but people would prefer Settings over this. Unless there are other ideas out there, I think at this point we should just fallback to the "make a new method making the setting explicit, and deprecate the old one" approach. It achieves the goal, on a case by case basis, without changing our back-compat policy nor adding any new Settings/actsAsVersion infrastructure to Lucene. Mike On Fri, May 22, 2009 at 2:20 PM, DM Smith <dmsmith...@gmail.com> wrote: > Michael McCandless wrote: >> >> On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey >> <mar...@rectangular.com> wrote: >> >>>> >>>> when working on 3.1 if we make some great improvement, I'd like new >>>> users in >>>> 3.1 to see the improvement by default. >>>> >>> >>> Sounds like an argument for more frequent major releases. >>> >> >> Yeah. Or "rebranding" what we now call minor as major releases, by >> changing our policy ;) Or "rebranding" to Lucene 2009. >> >> But: localized improvements (like the sizable performance gain from >> turning off scoring when sorting by field) should not have to wait for >> a major release to benefit new users. I think they should be on by >> default on the next release. > > This proposed policy change of allowing backward compatibility in the API to > change within a major release is nothing more than smoke and mirrors. But I > see two side effects: > 1) Debian, Fedora, and perhaps other Linux distributions, see minor releases > as maintaining backward compatibility. With Debian, they bump their major > revision number with each break in backward compatibility. I didn't check, > but my guess is that the version name of Lucene in Debian corresponds with > that of Lucene itself. I'd hate for that to change. How would you like to > see Debian to name it Lucene 4 or Lucene 5, when we are doing Lucene 3.x. It > gets confusing. (Real example: libsword7, which corresponds to the 1.5.11 > release of SWORD and libsword8 corresponds to 1.6.0.) > > 2) Backward compatibility of the index is at least 2 major revisions and > that is not proposed to change. Now with this, we effectively postpone it > indefinitely. Rather than the index being allowed to change when the API has > broken compatibility at most 2 times, with this proposed change, we can > break API compatibility a dozen times. At the future point where this policy > is brought into question, with something like "Now that we can break > backward compatibility in the API frequently, we need to change our policy > for the index to match", then we will have come full circle. > > At first, I liked the idea a lot, but now less so. Now I'm leaning toward > changing major revision number when backward compatibility changes and for > more frequent major releases if that is what it takes. > > This was the thrust of my tongue-in-cheek proposal of weekly minor and > monthly major releases. > > I also share Marvin's and others' concerns about sneaky bugs introduced by > globals. In my situation, Lucene is part of a desktop application and the > user can create hundreds of indexes and use them within the application. > With a *.deb or *.rpm, we'll have to specify that they cannot use anything > but the minor release for which the application was designed. Before, we > could say that one could drop in anything of the same major release number. > > I don't think I am alone or unique in embedding Lucene into a desktop > application. I know it is a part of Eclipse (at least on Fedora). > > This change might have the opposite effect of making people's perception of > Lucene as one of instability. Guard carefully against that, please! > > -- DM > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
