lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 10:20:33 GMT
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 <uwe@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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael Busch [mailto:buschmic@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<uwe@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: uwe@thetaphi.de
>> >>
>> >>
>> >>> -----Original Message-----
>> >>> From: Michael McCandless [mailto:lucene@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<earwin@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-unsubscribe@lucene.apache.org
>> >>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: java-dev-help@lucene.apache.org
>> >>
>> >>
>> >>
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: java-dev-help@lucene.apache.org
>> >
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message