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 Sun, 14 Dec 2008 15:40:25 GMT

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