> 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<rcm...@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-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > >> > > > > > -- > - Mark > > http://www.lucidimagination.com > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
