Then why go through all this trouble and not simply change the back-compat policy?
Really, I read some of Grant's responses and I realize that I've upgraded to 2.4 way too long ago. 2.9 is nowhere in sight. It takes a lot of time to release and during that time there's lots of discussions on the mailing list, lots of issues and so on. What I'm trying to say is that with the amount of communication on this mailing list, people have a lot of opportunities to pick up changes, in addition to the CHANGES file. In 2.9 we're breaking back-compat, with those "Changes in backward compatibility" section in CHANGES. So that makes it 2.4 and 2.9 in a row where back-compat was not delivered as promised. And how radical is it to ask people to update their code when they upgrade? Yes, if we were releasing every month, like was suggested previously, I can understand why it's important. But we're not. So changing my code every 6-9 months is not that bad. Most chances I'll change my code because of other things, not just Lucene. To me, all this Settings class (or actsAsVersion) will only complicate things. If I understand correctly, than in 2.9 we'll have the code defaulting to "actAs29", with the ability to change it to "actAs24". Doesn't that mean I need to update my code if I want to retain 2.4 behavior? If I already touch my code, how complicated is it to really match my app to 2.9? I mean, how many people write Collectors, and among those - how many Collectors do they write? We've gone through a hell lot of discussions in 1575 just to protect those who still use HitCollector, but I'm not sure how many users we actually protected. First, I think we should seriously consider to drop the "jar drop-in ability" requirement. I don't see any benefits from doing that, except for bug fixes. Second, usually the changes in runtime behavior is for improving things (such as performance) - so I don't see why we can't ask someone upgrading to a newer version to take advantage of those improvements. Grant suggested we discuss the back-compat policy, since if we resolve that we might not need Settings or actAs solution. I agree with that proposal. If we can relax our back-compat policy to the point of just the index structure (since between us, that's the most expensive thing you can hit when upgrading a Lucene version) then I don't think we need these Settings/actAs approaches. And BTW, the code today is already packed with deprecated methods, which neither Settings nor actAs will solve. So even by adopting new defaults, we'll still have troubles with back-compat, since we'll need to deprecate methods/classes and worse - find alternative names ! We could also decide to have X.0, X.5 and X+1.0 as point releases where back-compat changes (removing deprecated methods and changing defaults). That way we'll keep everybody happy, w/o needing to add Settings/actAs or wait 1-2 years before a major release is out. Shai On Wed, May 20, 2009 at 10:10 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Wed, May 20, 2009 at 12:55 PM, Andi Vajda <va...@osafoundation.org> > wrote: > > > I've been watching this thread with interest with my opinion swaying back > > and forth. > > So have I! > > > This last comment, though, pushes me to favor the settings class idea > > because that idea came with the promise of eliminating the combinatorial > > explosion of contructor and method overloads. > > > > In addition, I very much like the idea of having one place list all the > > coherent configuration choices one can make. No, CHANGES.txt is not it. > > While it's interesting reading, it reads like a blog. It doesn't tie > > sensible settings together. It only gives a differential and > chronological > > view of changes. > > > > Having version-specific settings classes is a really neat place to list > all > > possible settings in one place with sensible and coherent values for a > > version. > > The thing is... the number of settings will be large over time, and so > we'll need a hierarchy of classes, or we fallback to Properties w/ the > hierarchy encoded in the string, but then you have a weakly typed API, > and you lose the self-documenting (like Grant observed). > > Ie, in theory I love the idea of Settings, but in practice, as I start > to think about the realities of implementing it, I realize it's gonna > be a big challenge to solve it well. This goes waaay beyond resolving > the back-compat vs new users conflict we have today. > > Pushing to the way future, I'm also not convinced it's great that I > have to go to two places (IndexWriter and its *Settings counterpart) > to manage my "IndexWriter". > > I think the idea can work, but I'm realizing it's a huuuge project (vs > actsAsVersion which is quite simple). > > > The same idea could be used for other things than version by the > > way. It could help in picking one side of a configuration trade off over > > another. > > > > For example: > > - a settings for favoring speed of updates over speed of queries if > that > > makes sense > > - a settings for favoring index size over indexing speed > > ... and so on. > > Right -- Solr is discussing this now, too. I think this would be > useful. > > > I don't see why this has to be limited just to Lucene version backwards > > compatibility. > > I think we should do "actsAsVersion" today, solely to resolve the > back-compat vs new users conflict, and continue to explore/discuss > Settings for these other reasons. > > > Oh, and about that: I think we've reached the breaking point > > about backwards compatibility support a while ago. I recently hit a bug > in > > my code where a commit() call was missing. Before 2.4, flushing the index > > committed it. Starting with 2.4, this is no longer the case. Yes, this is > > documented and that helped me fix the bug really quickly but backwards > > compatible it is not. > > Hmm -- I think we should have had flush() just call commit(). > > > My point here is that we've promised too much > > backwards compatibility for too long and it's been getting too hard to > > deliver that promise now. > > I think it's high time we release 3.0 then! > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
