lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Finishing Lucene 2.9
Date Mon, 24 Aug 2009 12:27:53 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 :)

My nice TokenStream backwards layer will gone? Oh no :-) - Just kidding.


> 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



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