Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: "Uwe Schindler" <uwe@thetaphi.de>
To: <java-dev@lucene.apache.org>
References: <001601caadcf$d2b80030$78280090$@de>
 <293F8E54-7AA8-48DA-ACA2-F0916100D7F5@apache.org>
In-Reply-To: <293F8E54-7AA8-48DA-ACA2-F0916100D7F5@apache.org>
Subject: RE: [VOTE] Lucene Java 2.9.2 and 3.0.1 release artifacts
Date: Wed, 17 Feb 2010 23:50:17 +0100
Message-ID: <004301cab023$937bd2b0$ba737810$@de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcqwIYjb8Bqwm1wcT7GzHEK4USekswAAMUTg
Content-Language: de

Hi Grant, inline:

> Inline
>=20
> On Feb 14, 2010, at 6:45 PM, Uwe Schindler wrote:
>=20
> > 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:
> > http://people.apache.org/~uschindler/staging-area/lucene-292-301-
> take1-rev910082/
> >
>=20
> Still working through this, but:
>=20
> 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 apache.org already have =
sha1, so why remove them now?

>=20
> > =3D=3D=3D Proposed Release Announcement =3D=3D=3D
> >
> > 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=E2=80=99s commit and lost document deletes in near =
real-time
> indexing.
> > Also lots of bugs in Contrib=E2=80=99s Analyzers package were fixed.
>=20
> 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,
Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org