lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: [VOTE] Lucene Java 2.9.2 and 3.0.1 release artifacts
Date Wed, 17 Feb 2010 22:50:17 GMT
Hi Grant, inline:

> Inline
> On Feb 14, 2010, at 6:45 PM, Uwe Schindler wrote:
> > Hallo Folks,
> >
> > I have posted a release candidate for both Lucene Java 2.9.2 and
> 3.0.1 (which both have the same bug fix level, functionality and
> release announcement), build from revision 910082 of the corresponding
> branches. Thanks for all your help! Please test them and give your
> votes until Thursday morning, as the scheduled release date for both
> versions is Friday, Feb 19th, 2010. Only votes from Lucene PMC are
> binding, but everyone
> > is welcome to check the release candidate and voice their approval or
> disapproval. The vote passes if at least three binding +1 votes are
> cast.
> >
> > We planned the parallel release with one announcement because of
> their parallel development / bug fix level to emphasize that they are
> equal except deprecation removal and Java 5 since major version 3.
> >
> > Please also read the attached release announcement (Open Document)
> and send it corrected back if you miss anything or want to improve my
> bad English :-)
> >
> > You find the artifacts here:
> >
> take1-rev910082/
> >
> Still working through this, but:
> Why are there SHA1 signatures for the 3.0.1 releases but not 2.9.2.  I
> don't think SHA1 is required (in fact, isn't it cracked?) so it may be
> fine to just remove it.

Md5 is cracked, sha1 not (yet). We have the sha1 since 3.0 (its generated by 3.0's build.xml
since upgrade to ANT 1.7 because of fixed ant task definitions). And also all maven artifacts
require sha1, too, so its only 2.9's zip/tgz missing them. So I could simply generate them
manually for 2.9.2. The current 3.0.0 release on already have sha1, so why remove
them now?

> > === Proposed Release Announcement ===
> >
> > Hello Lucene users,
> >
> > On behalf of the Lucene development community I would like to
> announce the release of Lucene Java versions 3.0.1 and 2.9.2:
> >
> > Both releases fix bugs in the previous versions, where 2.9.2 is the
> last release working with Java 1.4, still providing all deprecated APIs
> of the Lucene Java 2.x series. 3.0.1 has the same bug fix level, but
> requires Java 5 and is no longer compatible with code using deprecated
> APIs. The API was cleaned up to make use of Java 5's generics, varargs,
> enums, and autoboxing. New users of Lucene are advised to use version
> 3.0.1 for new developments, because it has a clean, type safe new API.
> Users upgrading from 2.9.x can now remove unnecessary casts and add
> generics to their code, too.
> >
> > Important improvements in these releases are a increased maximum
> number of unique terms in each index segment. They also add fixes in
> IndexWriter’s commit and lost document deletes in near real-time
> indexing.
> > Also lots of bugs in Contrib’s Analyzers package were fixed.
> How about:  "Several bugs in Contrib's Analyzers package were fixed"
> Also, do these changes imply reindexing is needed?  If so, we should
> say so.

I have to go through this, but reindexing is not required, because the bugs were mostly missing
clearAttributes() calls leading to StopFilter integer overflows (with Version.LUCENE_30) -
and so crashes during indexing. Robert?

As always we preserve index compatibility, so we would not change behavior without adding
a new Version enum constant.

I will change the wording, Robert already sent me some grammar changes and a better overview
using bullted lists.

Thanks for reviewing,

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

View raw message