lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: Release 3.2 (was Re: Please mark distributed date faceting for 3.1)
Date Tue, 15 Feb 2011 19:34:59 GMT
On 02/15/2011 02:07 PM, Robert Muir wrote:
> On Tue, Feb 15, 2011 at 1:33 PM, Mark Miller<>  wrote:
>>> It appears to me, that the effort to commit the contributions are minimal, and
that in this case the true cost is that of doing the release.
>> Heh. I think looks can be deceiving sometimes. I'm not sure I'm willing to hold the
responsibility of those commits right now. If someone else is, that's great ... but I don't
find them minimal enough for my taste I suppose ;) Depends on what areas you feel comfortable
with I guess.
> Right, this is why some features with functional patches are sitting
> targeted at 3.2 instead of 3.1. Is it possible that we could put
> distributed date faceting (SOLR-1709), better cjk handling out of box
> (LUCENE-2906), and a better default merge policy (LUCENE-854) all in
> 3.1 right now? sure it is.
> But is this the best decision... I don't think it is.
Nor do I. I'm fine with the freeze.

>   I think as far
> as 3.1 goes we already have a great set of features that have baked
> for some time, including some rather serious performance improvements
> (Mike and I have done some benchmarking against 3.0)... and its
> already going to be a more challenging release since its the first one
> since we merged lucene and solr.
> For these newer features, its not that we are lazy...

I did not mean to suggest that anyone is lazy. Far from it, the effort 
that goes into this project is impressive.

> its that
> sometimes you want more tests, want things to "bake" for a while with
> hudson's random testing, perhaps want some reviews/second pairs of
> eyes on the code, or maybe even just some more time to think about the
> change before committing to it.
I have a personal interest in LUCENE-2906. If there is anything I can do 
to help it along, I'll be glad to do that. I'll take it up on that issue.
> When we commit it and release it, we are signing up for some degree of
> support in the future. Also, personally I think its better to put out
> a good release with solid code and a few less features, than a more
> buggy release that has a couple of extra features.

As I said, I'm happy with 3.1 being frozen. This release is much more 
timely. :) In the past, I saw releases being repeatedly pushed out to 
get one last thing in. (Maybe it just appeared that way to me.)

-- DM

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

View raw message