> > With the new way, you can get the first bug fix release, but then you will > quickly be left out of new bug fixes until you update your code.
Mark, apologies for the late reference, but it struck me only after I left the computer yesterday. Again, I'm not sure how bit of a problem is it. Suppose that I upgrade to 2.4 and the next version (6 months?) is 2.9. Then a bug is discovered and is fixed in 2.4.1 and 2.9. In addition, 2.9 contains all these changes in Collectors. When 2.9 is out I decide not to upgrade to 2.9 because I don't have time. When 3.0 comes out (3-4 months later?) I will be forced to upgrade. That means ~1 year since I last upgraded my Lucene code sections. (True, if there will be any bug fixes in 2.9, I will miss them). How unreasonable is to ask this? Seriously, how many apps are not touched *at all* during one year? And even if these code segments are stable and no one touches them anymore, how problematic is it to request users to once a year do a sort of cleanup and update to their code? In other words, we keep deprecated around for only one or two versions. That is a reasonable approach. Meaning, defaults may change between releases because we'd like Lucene users to get the latest & greatest stuff, (and also count on the fact not so many out there strongly rely on the defaults?) but methods removal/rename should cause a little more trouble, so we can give the users one release to arrange their time before they have to do anything. Maybe the TokenStream API needs to stay deprecated for longer, until we're sure everybody is happy with the new API. Shai On Thu, May 21, 2009 at 4:23 AM, Grant Ingersoll <gsing...@apache.org>wrote: > > On May 20, 2009, at 4:06 PM, Michael McCandless wrote: > > On Wed, May 20, 2009 at 3:24 PM, Shai Erera <ser...@gmail.com> wrote: >> >>> Then why go through all this trouble and not simply change the >>> back-compat >>> policy? >>> >> >> Back-compat is insanely costly, especially the longer it takes us to >> get to the next major release... yet, the specific cost that bothers >> me the most is that we hurt our new users because of the back-compat >> users. It hurts Lucene's adoption/growth. >> >> Another consideration on relaxing policy is that back-compat is well >> nigh impossible to actually achieve. We spend an insane amount of our >> energy maintaining back-compat, but then one accidental breakage that >> slips through quickly causes many back-compat users to conclude we are >> not back-compat. It's not much bang and alot of buck. >> >> It is tempting to change our policy to something like: >> >> * Bug fixes only on each 2.4.X release >> >> * Anything can change on each 2.X release, but any prior 2.Y index >> format is readable >> >> I think it's not unreasonable to say "if you want to take advantage of >> Lucene's perf improvements and new features, on upgrading you'll have >> to recompile, fix APIs, etc.". >> > > > All reasonable, Mike. My take is that Lucene has always been pragmatic > about darn near everything, except back compat, where we are pretty > dogmatic. > > In general, I think it is reasonable to say that even from 2.x to 2.y we > will try to be back compatible, but when we deem it necessary, we reserve > the right to change things. I don't think anyone here is suggesting we > would ever do something drastic like a complete overhaul of all the APIs in > a version change. I also think it is reasonable to deprecate things by > saying @deprecated Will be removed in 2.Y. Use coolNewMethod instead. In > other words, we keep deprecated around for only one or two versions. Of > course, the timing can vary. Things like changing the Document stuff like > we've talked about might last longer (or shorter, actually) while minor > deprecations may only be kept for one. The index compatibility stuff is a > must. > > It is probably worthwhile to ask on java-user@ how many people rely on our > back compat policies. > > <tongue in cheek> Of course, we do already support back compat for all > versions: svn checkout > http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_1/ </tongue > in cheek> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
