You didn't really comment on my proposal: I suggested to not remove the
old Token API and old queryparser in 3.0. Instead with 3.0 change the
bw-policy, so that we can remove deprecated things in minor releases
(e.g. 3.1 in this case).
I think your 2.5 proposal has drawbacks: if we release 2.5 now to test
the new major features in the field, then do you want to stop adding new
features to trunk until we release 2.9 to not have the same situation
then again? How long should this testing in the field take?
Michael
On 8/10/09 12:26 PM, Grant Ingersoll wrote:
On Aug 10, 2009, at 3:06 PM, Michael Busch wrote:
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.
Maybe. I'm not convinced yet that the current QP should go away
either. The new QP sounds good and all paper, but from the looks of
it at first glance, it is complicated (a whole package filled with
classes just to implement the old QP versus a single JavaCC file and a
single Java class), while the old one has been around for a long time
and seen a lot of field use (and admittedly has warts), whereas both
the new QP and the new Token stuff are essentially last minute
additions to a last minor release right before we are about to do a
major release and remove a whole bunch of deprecated APIs and
essentially commit to these new ways of doing things without any field
testing. And I haven't even mentioned the new per-segment stuff yet.
This is my reason for suggesting 2.5. It gives us some real running
time before we have to commit to them. If I had to vote on 2.9 today
in light of what it means for 3.0, it likely would be -1.
-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
