lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven A Rowe <>
Subject RE: [VOTE] Release Lucene/Solr 3.2.0
Date Mon, 30 May 2011 20:06:59 GMT
First, I want to say that I think being able to release more frequently is great.  Thanks Mike
for taking the initiative.

But we need to be able to fix packaging problems, and the only time we look at them is at
release time.  So I'm -1 to the idea of ignoring problems because we don't want to hold back
releases.  Re-spinning must remain a real option.

Another random thought: we have had a tradition of spending time fixing docs prior to a release.
 I don't think this makes sense anymore: releasing should be as rote as possible.  But I don't
think our docs should suffer as a result of this shift.  This implies that we should be looking
harder at documentation when things get committed.  (This is a good thing.)


Release blocking issues:

1. Snowball license:

 On 5/30/2011 at 8:22 AM, Doron Cohen wrote:
> 3) Lucene src pack contains SNOWBALL-LICENSE.txt which is
> not in either of the two binary packages, is this a problem?

-1 to RC1 based on this.  Unlike the other license files in the source distribution, which
cover external .jar dependencies (in various lib/ directories in the source archive, but not
in the release archives), the Snowball license covers content in the released Lucene binaries.

2. Source archive broken build:

> 5) running 'ant clean' (or any target) from tarsrc/lucene-3.2.0
> fails due to dependency in ../common-build.xml.

-1 to RC1 based on this.  The source tarball needs to be usable.  At present, nothing in the
missing imported file is used in the Lucene build, so the <import> tag in lucene/common-build.xml
could be removed.  Alternatively, adding the attribute optional="true" to the <import>
tag allows the build to function.

3. Contrib Javadocs include links to removed contribs ant, db, lucli, and swing. -1 to RC1
based on this.

Non-blocking issues:

1. NOTICE.txt refers to .jar files and the corresponding LICENSE files in various lib/ directories,
which are not included in the binary archives.  Should we have a way to automatically strip
these things from the source NOTICE.txt to form a release NOTICE.txt?

2. CHANGES.txt has no release date for 3.1.0 - although we've stopped putting dates on RCs'
CHANGES.txt for the release-to-be, we should add dates to CHANGES.txt for past releases.


Starting the example server and posting the example docs (following example/README.txt) works
for me from the .tgz binary archive, as does building/running the tests from the source archive,
though I had to switch to a 1.6 JVM to get the tests to complete - under Win7 with a 1.5 JVM,
there were build failures related to file deletion problems.

Release blocking issues:

1. Default to the new Tiered flush policy:

On 5/29/2011 at 10:42 AM, Mark Miller wrote:
> The only thing I am concerned about is that Solr does not use
> VERSION_32 in the example and so does not use the new Tiered
> flush policy.  I do think that's worth a respin

I agree.  -1 to RC1 based on this.

2. All contrib/*/CHANGES.txt have "3.2-dev" as the release header.  -1 to RC1 based on this.


> -----Original Message-----
> From: Michael McCandless []
> Sent: Friday, May 27, 2011 11:50 AM
> To: Dev
> Subject: [VOTE] Release Lucene/Solr 3.2.0
> Please vote to release the artifacts at:
> as Lucene 3.2.0 and Solr 3.2.0.
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message