lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Finishing Lucene 2.9
Date Mon, 24 Aug 2009 12:21:13 GMT
You make a great point. If we jump to 3.0, what do we do about the
deprecation drop?

If we drop them now, it would be quite a fun upgrade experience :)

- Mark

Tim Smith wrote:
> 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<rcmuir@gmail.com> 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: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>   
>


-- 
- Mark

http://www.lucidimagination.com




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