Exactly ! which is why I think we should relax the back-compat policy "a bit".
And ... (I realize it's going to complicate things a bit) we could also decide to have dot release for bug fixes, like we had 2.4.1. So let's say when 3.4 comes (3-4 years from now :) ). In 3.6 we don't preserve any back-compat. If there is a bug, we fix it on 3.6 and also on a 3.4.1 branch. Those that just want to take the bug fixes can upgrade to 3.4.1. Those that upgrade to 3.6 get the bug fixes and all the rest of the changes done, so they should be ready to change their code. I don't think we should maintain 3.4.1-like releases for too many releases though. I.e., as soon as 3.6 is out, no bugs are fixed on the 3.4 branch, just 3.6. On Wed, May 20, 2009 at 10:33 PM, Earwin Burrfoot <ear...@gmail.com> wrote: > In fact, there's no reason to upgrade Lucene (save for bigfixes), if > you absolutely require a drop-in jar, and don't want to touch any of > your code. > See, you upgrade either for new features, or for performance > improvements. You have to write code for former, and you have to write > code for the latter (because by default most of them are off). So, if > you're not ready to patch your app, you don't get any of this, so why > bother upgrading at all? > > On Wed, May 20, 2009 at 23:24, Shai Erera <ser...@gmail.com> wrote: > > 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 > >> > > > > > > > > -- > Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
