I do agree 2.9 has tons of changes: new analysis API, segment-based searching/collection/sorting, new QP, etc.
One option might be to have a looong beta period for 2.9, and focus on testing/docs? Or... and this is one crazy idea... maybe we should simply release 3.0 next, not removing any deprecated APIs until 3.1 or later. Ie, "normal" software on having so many major changes would release an X.0 release; I agree the "deprecation release" is unusual. This way users would realize/expect 3.0 to have major changes. Mike On Mon, Aug 10, 2009 at 4:37 PM, Michael Busch<busch...@gmail.com> wrote: > On 8/10/09 1:30 PM, Grant Ingersoll wrote: >> >>> >>> 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? >> >> I don't know. How long does any release cycle last in Lucene? >> > > But we'll always have the same problem, no? We need to find a solution that > allows us to keep adding features; dedicated "deprecation" releases are not > good. > > --------------------------------------------------------------------- > 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
