lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: 2.9, 3.0 and deprecation
Date Thu, 18 Dec 2008 22:13:55 GMT

Any more thoughts on this...?

This seems like a big confusion (whether we can deprecate X without  
introducing new API Y, in 2.9 -- I don't see how), at least for me,  
holding up 2.9.

Mike

Michael McCandless wrote:

>
> Grant Ingersoll wrote:
>
>>
>> On Dec 14, 2008, at 6:54 AM, Michael McCandless wrote:
>>
>>> I'd also personally like to see 2.9 released sooner rather than  
>>> later,
>>> maybe earliesh next year?
>>>
>>> I don't think we should hold up 2.9 for some of the big items below
>>> (eg Fieldable/AbstractField/Field cleanup), especially if they have
>>> not even been started yet.
>>
>> Well, if they are going to be changed, they need to at least be  
>> deprecated, right?
>
> But we can't deprecate old APIs until we've added new APIs, in a  
> release?
>
>> 2.9 has turned into a feature release, when that has never been the  
>> plan.
>
> Good point, though is that a problem?  I suppose we could do a 2.5  
> release before 2.9, if so.
>
>>> One question: I'm assuming after 2.9 is out, we would fairly quickly
>>> follow that up with a 3.0 that has more or less just removed  
>>> deprecations?
>>> (Vs doing alot of dev putting new features into 3.0 as well).
>>>
>>> More comments below:
>>>
>>> Grant Ingersoll wrote:
>>>
>>>> 1. Splitting Index time Document from Search time Document per  
>>>> Hoss' ideas on a variety of threads in the past.  Something to  
>>>> the gist of having an InputDocument and an OutputDocument (and  
>>>> maybe an abstract Document for shared features) such that people  
>>>> wouldn't be confused about calling index time things on Document  
>>>> during search and vice versa.
>>>
>>> Maybe don't hold 2.9 for this one?  (There's been lots of  
>>> discussion, and also recently interesting discussion on adding  
>>> type safety to Document under LUCENE-831, but nothing yet concrete).
>>
>> As I said above, I don't see how we can.  Either it gets deprecated  
>> now (note, we don't have to have the new version now) or it doesn't  
>> get changed for 3.x is my understanding of the process.
>
> OK I guess I don't understand the "note, we don't have to have the  
> new version now" -- was this done in the past?  Ie in 1.9 we  
> deprecated APIs not knowing what the future migration path would  
> be?  And then in 2.0 development the replacement was completed &  
> available & deprecated APIs were then removed?
>
> Mike


---------------------------------------------------------------------
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