lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Finishing Lucene 2.9
Date Mon, 24 Aug 2009 12:26:40 GMT
This is exactly my own opinion. I would only add Java 1.5 with generics to
public API (most important the TokenStream stuff and also Field, also
NumericRangeQuery is prepared for generics: NumericRangeQuery<? Extends
Number>). I do not want to add generics everywhere inside, but to the public




Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen


From: Tim Smith [] 
Sent: Monday, August 24, 2009 2:19 PM
Subject: Re: Finishing Lucene 2.9


Here's my vote on the topic of 2.9 vs 3.0

Next release should be 2.9
This release provides TONs of new APIs for things like Hit Collection,
Scoring, Sorting, etc
If all the deprecated stuff were removed for the "next" release, this would
be impossible for any application developer to consume (unless they are
using very light high level use of lucene APIs)

I would then vote for a very fast turnaround on 3.0 
deprecations removed, generics added, performance improvements possible with
java 1.5, but no major new features
I would argue that small features should be allowed in (provided they would
not cause any postponement to 3.0 going out soon)

This allows me (as a application developer) to do the following:
upgrade to 2.9 (port my code to use all the new APIs)
hopefully, once i have fully ported everything to 2.9, 3.0 will now be ready
(or will be soon)
then, i can drop in 3.0 (very minor porting required here) and all the
deprecated APIs with their slowing "wrapper" code for back-compat will now
be gone, along with improvements in using StringBuilder instead of
StringBuffer, generics, and other performance improvements.

I would hope to never release any of my code running 2.9 and instead release
with 3.0, however as a app developer, i need 2.9 as a bridge for porting

 -- Tim

Michael McCandless wrote: 

On Sun, Aug 23, 2009 at 1:38 PM, Robert Muir <>
<> wrote:

But isn't it also true it could be a bit more than no-op:
1) changing to "better" defaults in cases where back compat prevents
this. I think I remember a few of these?
2) bugfixes found after release of 2.9
3) performance improvements, not just from #1 but also from removal of
back-compat shims (i.e. tokenstream reflection)

Sorry, right, there are some defaults we will change.
We may get bugfixes in, but if it's truly a "fast turnaround release",
I think there wouldn't be that many bug fixes.
And I agree on performance improvements for cases where the back
compat emulation code was hurting performance.
It seems like we have two questions:
  * Do we label the next release 2.9 or 3.0?
  * After that next release, do we do a "fast turnaround" release or a
more normal "take your time and do real work" release?
To unsubscribe, e-mail:
For additional commands, e-mail:


View raw message