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