Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Date: Thu, 19 May 2011 10:44:12 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: dev@lucene.apache.org
cc: simon.willnauer@gmail.com
Subject: Re: Moving towards Lucene 4.0
In-Reply-To: <BANLkTikxfUJv-VcZKQGpbxXOK-DmELknPw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1105191033522.30892@bester>
References: <BANLkTimd1QFeGWhGJBeqB1s_21GcGVax9g@mail.gmail.com>
 <BANLkTikxfUJv-VcZKQGpbxXOK-DmELknPw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org