This is exactly my own opinion. I would only add Java 1.5 with generics to public API (most important the TokenStream stuff and also Field, also NumericRangeQuery is prepared for generics: NumericRangeQuery<? Extends Number>). I do not want to add generics everywhere inside, but to the public API.
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de _____ From: Tim Smith [mailto:tsm...@attivio.com] Sent: Monday, August 24, 2009 2:19 PM To: java-dev@lucene.apache.org Subject: Re: Finishing Lucene 2.9 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 <mailto:rcm...@gmail.com> <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
