lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
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.


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:
For additional commands, e-mail:

View raw message