lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: 2.9, 3.0 and deprecation
Date Sun, 14 Dec 2008 13:45:12 GMT

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?  2.9 has turned into a feature release, when that  
has never been the plan.

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

>> 2. Java 1.5  (who knows, maybe by 2020, we can be on 1.6!).  This  
>> means we can use Generics, or as I like to call them "Specifics"  
>> since the specifically say what is in the collection as opposed to  
>> the current collections where you can put any generic object in  
>> them. :-)
> We get this one "for free" ;)

Of course.

>> 3. Michael B. is proposing a new Token API (but it's back compat.)
> Already in and quite a big cutover.
>> 4. Mike M. is doing some new flex indexing stuff (but it's back  
>> compat.)
> I would not hold 3.0 for this; it's still big & exploratory at this  
> point.

Again, merely making the point that if we are going to have API  
changes, we need to deprecate now.

>> 5. Is there anything we would need to deprecate now if we were to  
>> take advantage of 1.5 concurrent packages?
> Has anyone looked into this?
>> 6. Local Lucene is of interest to a lot of people.  Does it require  
>> anything special in terms of deprecation? (me thinks not)
> Any more clarity on this?  I would also assume not.
>> 7. Same goes for the real time stuff, PFOR implementation, column- 
>> stride fields, etc.
> I think we tackle real-time needs one by one (eg LUCENE-1484,  
> removing sync on IndexReader.document(), which I'm working on now,  
> doesn't deprecate anything).  PFOR I think is blocked by flex  
> indexing.  Column-stride fields would be great to get it, but  
> doesn't seem to have any forward motion for quite a while...
>> 8.  I think we should do a review of what's open in JIRA again and  
>> see if we can come to conclusions on any of them, such that going  
>> into 3.0, JIRA is relatively clean.
> I've been trying over time to mark things as fix version 2.9, so we  
> are at least forced to review them come 2.9.
>> 9. For 3.0, what cruft from 1.x can we remove from the file format,  
>> since 3.x need not read 1.x format _if_ doing so is advantageous to  
>> us?
> I'm not sure offhand.  There's alot of scary cruft in  
> SegmentInfo.files(), but it's from 2.0 -> 2.1 so we need to keep it  
> for now (to remove in 4.0, in 2020 ;) ).
>> 10. There has been some talk about changing how StandardTokenizer  
>> labels some tokens.  What can we do in there to deprecate?
> I think we need a more incremental approach, somehow, for  
> StandardTokenizer.  Like it does its own internal versioning or  
> something.  There have been lots of little cases over time where it  
> needs fixing, yet, it would be a break in back compat to fix them.
>> 11. Fieldable.  Ah, Fieldable.  I believe this is going to become  
>> an abstract base class, or go away.
> This is a biggie and nobody's stepped up so far to tackle it... I  
> would say don't hold up 2.9 for this.

We could deprecate for now.

> Maybe add these ones:
> 12. LUCENE-1483 -- running Scorer & HitCollector "per segment".  We  
> are making good progress here, and uncovering some nice per-query  
> performance wins plus much faster searcher warming (sicne FieldCache  
> is only used per-segment).  On the current path it looks likely to  
> deprecate current Field sorting classes, so it'd be great to get  
> this in before 2.9.
> 13. LUCENE-831 (new FieldCache API).  This is long standing and  
> there's a fair amount of interest, and through our iterations with  
> LUCENE-1483 (one of the primary users of the FieldCache API, field  
> sorting) we are getting more clarity on what a new FieldCache API  
> should look like.  It'd be nice to resolve before 2.9, and I'd like  
> to spend time doing so (after / with LUCENE-1483).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message