On Thu, May 19, 2011 at 21:44, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : 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.
How do I express my profound love for these words, while remaining chaste? : ) > 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 > > -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org