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

Reply via email to