Right: 3.0 should be a fast turnaround w/ no further deprecations. (And at your rate of progress Uwe it looks like it really *will* be fast!).
For 3.1 we can salivate... Mike On Sat, Oct 3, 2009 at 6:18 AM, Uwe Schindler <u...@thetaphi.de> wrote: > But we should not change for 3.0, because people have already much to do to > get their 2.9 compile without deprec. If the work is then obsolete, because > we change this fundamental, we will make a lot of people angry. So I would > do this for 3.1. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -----Original Message----- >> From: Michael Busch [mailto:busch...@gmail.com] >> Sent: Saturday, October 03, 2009 12:15 PM >> To: java-dev@lucene.apache.org >> Subject: Re: Lucene 2.9 and deprecated IR.open() methods >> >> There's also LUCENE-1698! Maybe we can change the policy. Now that 2.9 >> is out we should try to get to a conclusion. >> >> Michael >> >> On 10/3/09 11:54 AM, Michael McCandless wrote: >> > Well, let's first get 3.0 out the door ;) Then we can salivate over >> > all sorts of juicy changes for 3.1... >> > >> > These particular changes (switching syntax from multi-ctors to config >> > or to builder, disallowing config changes after creation, switching to >> > "concrete impl is hidden") may merit an exception to our back-compat >> > policy. Obviously users are bothered by the horror of how many ctors >> > you are confronted with for IW and IR. >> > >> > Mike >> > >> > On Sat, Oct 3, 2009 at 5:46 AM, Uwe Schindler<u...@thetaphi.de> wrote: >> > >> >> Hi, >> >> >> >> The problem is, we have to leave some of the not-yet-deprecated >> ctors/opens >> >> available for a while (not until 4.0 with our ne policy), but a user >> >> removing all deprecated stuff from his 2.9 release should be able to >> switch >> >> to 3.0 without changing any code (can even plug the jars in). We also >> have >> >> to keep the getters/setter avail. If we wanted to change this, 2.9 was >> the >> >> best option :-( >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> H.-H.-Meier-Allee 63, D-28213 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> >> >>> -----Original Message----- >> >>> From: Michael McCandless [mailto:luc...@mikemccandless.com] >> >>> Sent: Saturday, October 03, 2009 11:35 AM >> >>> To: java-dev@lucene.apache.org >> >>> Subject: Re: Lucene 2.9 and deprecated IR.open() methods >> >>> >> >>> On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot<ear...@gmail.com> >> wrote: >> >>> >> >>>>> Call me old fashioned, but I like how the non constructor params are >> >>>>> >> >>> set >> >>> >> >>>>> now. >> >>>>> >> >>>> And what happens when you index some docs, change these params, index >> >>>> more docs, change params, commit? Let's throw in some threads? >> >>>> You either end up writing really hairy state control code, or just >> >>>> leave it broken, with "Don't change parameters after you start >> pumping >> >>>> docs through it!" plea covering your back somewhere in JavaDocs. >> >>>> If nothing else, having stuff 'final' keeps JIT really happy. >> >>>> >> >>> This is a good point: are you allowed to change config settings after >> >>> creating your IndexWriter/Reader? >> >>> >> >>> Today it's ad hoc. >> >>> >> >>> EG IW does not allow you to swap out your deletion policy, because >> >>> it'd be a nightmare to implement. You also can't swap the analyzer. >> >>> But it does let you change your RAM buffer size, CFS or not, merge >> >>> factor, etc. We can remove that flexibility (I'm not sure it's >> >>> compelling), so we can make things final. You can't change read-only >> >>> after opening your IndexReader. I think it'd make sense to move away >> >>> from changing settings after construction... >> >>> >> >>> But: the "do we disallow changing config settings after construction?" >> >>> question is really orthogonal to the "what syntax do we use for >> >>> construction?" (builder vs config vs zillions-of-ctors). >> >>> >> >>> Mike >> >>> >> >>> --------------------------------------------------------------------- >> >>> 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 >> >> >> >> >> >> >> > --------------------------------------------------------------------- >> > 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 > > > > --------------------------------------------------------------------- > 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
