: I think we should focus on everything that's *infrastructure* in 4.0, so : that we can develop additional features in subsequent 4.x releases. If we : end up releasing 4.0 just to discover many things will need to wait to 5.0, : it'll be a big loss.
the catch with that approach (i'm speaking generally here, not with any of these particular lucene examples in mind) is that it's hard to know that the infrastructure really makes sense until you've built a bunch of stuff on it -- i think Josh Bloch has a paper where he says that you shouldn't publish an API abstraction until you've built at least 3 *real* (ie: not just toy or example) implementations of that API. it would be really easy to say "the infrastructure for X, Y, and Z is all in 4.0, features that leverage this infra will start coming in 4.1" and then discover on the way to 4.1 that we botched the APIs. what does this mean concretely for the specific "big ticket" changes that we've got on trunk? ... i dunno, just my word of caution. : > we just started the discussion about Lucene 3.2 and releasing more : > often. Yet, I think we should also start planning for Lucene 4.0 soon. : > We have tons of stuff in trunk that people want to have and we can't : > just keep on talking about it - we need to push this out to our users. I agree, but i think the other approach we should take is to be more agressive about reviewing things that would be good candidates for backporting. If we feel like some feature has a well defined API on trunk, and it's got good tests, and people have been using it and filing bugs and helping to make it better then we should consider it a candidate for backporting -- if the merge itself looks like it would be a huge pain in hte ass we don't *have* to backport, but we should at least look. That may not help for any of the "big ticket" infra changes discussed in this thread (where we know it really needs to wait for a major release) but it would definitely help with the "get features out to users faster" issue. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
