lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 10:22:39 GMT
I agree, we have announed the 2.9/3.0 release plans a long time ago 
already and shouldn't change anything. But ideally I'd like to announce 
any backwards-compatibility changes together with the 3.0 release, while 
mentioning that the changes will take effect from 3.1 on. That's why I'd 
like to get to a conclusion soon.

  Michael

On 10/3/09 12:18 PM, Uwe Schindler 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