On Wed, Apr 14, 2010 at 12:49:52AM -0400, Robert Muir wrote:
> its very unnatural for release 3.0 to be almost a no-op and for release 3.1
> to provide a new default index format and support for customizing how the
> index is stored. And now we are looking at providing flexibility in scoring
> that will hopefully redefine lucene from being a vector-space search engine
> library to something much more flexible? This is a minor release?!
I agree, but what really bothers me are the X.9 releases.
2.9 changed performance characteristics dramatically enough that it was a
backwards-break in all but name for many users -- most prominently, Solr[1].
Solr's FieldCache RAM requirements doubled because of the transition to
per-segment search. And 2.9's backwards compatibility layer in TokenStream
was significantly slower.
In my opinion, the transition to per-segment search and new-style TokenStreams
should have triggered a major version break. Had that been the case, less
effort could have been spent on backwards compatibility shims and fewer API
design compromises would have been necessary.
To avoid such costs in the future, and to communicate disruptions in the
library to users via version numbers more accurately...
* There should not be a Lucene 3.9.
* Lucene 4.0 should do more than remove deprecations.
Marvin Humphrey
[1] Thanks to Robert and Mark Miller for reminding me just what the
Solr/Lucene-2.9 problems were via IRC.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
