lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Smith <>
Subject Re: Finishing Lucene 2.9
Date Mon, 24 Aug 2009 12:19:05 GMT
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

 -- 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?
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message