On Feb 17, 2010, at 5:50 PM, Uwe Schindler wrote: > 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?
Yes. Both "weak": http://www.apache.org/dev/release-signing.html. But, I think we are fine b/c you have the 4K bit key. No need to remove. > >> >>> === 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. > Cool. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
