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: > > http://people.apache.org/~uschindler/staging-area/lucene-292-301- > 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 apache.org 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, Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
