lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <>
Subject Re: Moving towards Lucene 4.0
Date Fri, 20 May 2011 06:42:58 GMT
On Thu, May 19, 2011 at 7:44 PM, Chris Hostetter
<> 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.

yeah big +1 - everybody should watch that tech talk... ( )
> 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.

I agree, we should backport what we can but we have to ensure some
balance between
amount of work vs. benefit. I mean one big thing which we could port
is DWPT almost all the other features
rely on the new flex API. So I am not sure if there is anything else
really.... well DocValues could be easy actually.

I still want to remind that we should not wait for too long with 4.0!

> 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:
For additional commands, e-mail:

View raw message