I think we should change the backwards-compatibility policy as proposed
in LUCENE-1698 and remove some deprecated things (inlcuding the old
TokenStream API, maybe query parser) in 3.1, not 3.0.
I don't think we should have a 2.5 release - this clearly shows the
disadvantages of our current bw-policy.
Michael
On 8/10/09 11:50 AM, Grant Ingersoll wrote:
On Aug 10, 2009, at 2:00 PM, Earwin Burrfoot wrote:
I'll deviate from the topic somewhat.
What are exact benefits that new tokenstream API yields? Are we sure
we want it released with 2.9?
By now I only see various elaborate problems, but haven't seen a
single piece of code becoming simpler.
In theory, it sets up for more indexing/searching possibilities in
3.0, but in the meantime, it is proving to be quite problematic due to
back compatibility restrictions.
I have serious doubts about releasing this new API until these
performance issues are resolved and better proven out from a usability
standpoint.
It simply is too much to swallow for most users, as
Analyzers/TokenStreams/etc. are easily the most common place for
people to inject their own capabilities and there is no way we should be
taking a 30% hit in performance for some theoretical speed up and new
search capability 1 year from now.
I'm almost thinking we should have a 2.5 release instead of 2.9. I
know, that stinks, because we all want to get onto 3.0, but the fact
is, 2.9 was _SUPPOSED_ to be a deprecation release,
when in reality it probably has as many changes as 2.3 did and it has
a lot of back compatibility breakages. Going to 2.5 would give this
token stuff a chance to marinate, as well as
all the per segment changes and the NRT stuff. Just a thought.
-Grant
---------------------------------------------------------------------
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
