lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: [VOTE] Release Lucene/Solr 3.2.0
Date Sun, 29 May 2011 08:14:07 GMT
On Sun, May 29, 2011 at 3:27 AM, Simon Willnauer
<> wrote:
> and we
> the lucene PMC agreed on the fact that a release doesn't need to have
> large features. We simply don't want to let folks wait for years
> anymore.

I think its a lot more than this really... I think we should consider
all of the following things:

* the list of features we have in 3.2 is actually digestible, its
probably bad to wait until we have this huge intimidating list of
changes to release, from casual browsing I don't see huge long lists
from other open source projects.
* if a user contributes something, I think its really important to
turn that around into a release faster, its going to encourage them to
contribute again. Sure, to those of us in the choir we are ok with
contributing stuff knowing its moving the project along long-term, but
I think for more casual contributors turn-around is really
important... they are most likely using releases not SVN and are
interested in when their contribution will be in a release.
* we have a growing list of committers and activity on the project and
I think speeding up the release cycle reflects our productivity level,
I think the list of features in 3.2 is quite nice and will benefit a
pretty large percentage of the userbase.
* we are talking about issuing off our stable branch, which has the
benefit of getting backports of things that have baked for a while in
trunk (e.g. TieredMP baked before being backported). We take the time
to maintain this stable branch, we should exploit it for all its worth
and get safe features out there.
* we are way more aggressive about bugs lately, its not just
patch+test, but instead, identify the general problem, fix it across
the board, and share the same mechanism with users to test their own
code (e.g. and are some recent
examples of this)
* we did all this infra work to make releasing faster... its so much
better now, I can list all of the things I've done to validate/fixup
releases before (test under different locales, fix javadocs warnings,
license problems), and all of this stuff is automatic now.

So these are some of the reasons why I think it makes perfect sense to
try to crank out releases from our stable branch that are incremental
and evolutionary versus revolutionary.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message