I thought that the index file format is supposed to be supported until the 2nd major release. I.e. 3.0 will still read 2.0 indexes, but 4.0 won't. Is that what you meant, or am I wrong?
Shai On Thu, May 21, 2009 at 2:17 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > OK so it sounds like we've boiled the proposal down to two concrete > changes to the back-compat policy: > > 1) Default settings can change; we will always choose defaults based > on "latest & greatest for new users". This only affects "runtime > behavior". EG in 2.9, when sorting by field you won't get scores > by default. When we do this we should clearly document the > change, and what settings one could use to get back to the old > behavior, in CHANGES.txt. > > 2) An API, once released as deprecated, is fair game to be removed > in the next minor release. > > We still only make bug fixes on point releases, support the index file > format until the next major release -- those don't change. > > Mike > > On Wed, May 20, 2009 at 11:34 PM, Shai Erera <ser...@gmail.com> wrote: > >> 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 > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
