On Tue, 24 Nov 2009, Uwe Schindler wrote:

I will add the tag, when it is officially voted for release. If we respin,
the tag would be incorrect (and must be removed and recreated). The release
todo clearly says, that the tag should be added when all votes are there,
and all other did this like this before.

Just one more day and I will create the tag (if I get 2 more votes).

So I'm in a catch-22. I was going to vote if I could build a PyLucene from this and pass all PyLucene tests :)

Do you happen to know what svn rev was used to build the artifacts ?
I could use that rev instead of HEAD.

Andi..


Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


-----Original Message-----
From: Andi Vajda [mailto:va...@osafoundation.org]
Sent: Tuesday, November 24, 2009 6:46 PM
To: java-dev@lucene.apache.org
Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2)


  Hi Uwe,

On Sun, 22 Nov 2009, Uwe Schindler wrote:

I have built the artifacts for the final release of "Apache Lucene Java
3.0.0" a second time, because of a bug in the TokenStream API (found by
Shai
Erera, who wanted to make "bad" things with addAttribute, breaking its
behaviour, LUCENE-2088) and an improvement in NumericRangeQuery (to
prevent
stack overflow, LUCENE-2087). They are targeted for release on 2009-11-
25.

The artifacts are here:
http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-take2/

The artifacts you've prepared don't correspond to the HEAD of the
lucene_3_0 branch anymore since fixes for bugs 2086 and 2092 were added.

Could you please add a lucene_3_0_0 tag that corresponds to the artifacts
?
This makes it easier to build a PyLucene with Lucene Java sources
equivalent
to these artifacts, using Lucene Java's svn.

Of course, if another revision of these artifacts ends up being made, the
tag should then move accordingly but, at this point, it's just missing.

Thanks !

Andi..


You find the changes in the corresponding sub folder. The SVN revision
is
883080, here the manifest with build system info:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_22-b03 (Sun Microsystems Inc.)
Specification-Title: Lucene Search Engine
Specification-Version: 3.0.0
Specification-Vendor: The Apache Software Foundation
Implementation-Title: org.apache.lucene
Implementation-Version: 3.0.0 883080 - 2009-11-22 15:52:49
Implementation-Vendor: The Apache Software Foundation
X-Compile-Source-JDK: 1.5
X-Compile-Target-JDK: 1.5

Please vote to officially release these artifacts as "Apache Lucene Java
3.0.0".

We need at least 3 binding (PMC) votes.

Thanks everyone for all their hard work on this and I am very sorry for
requesting a vote again, but that's life! Thanks Shai for the pointer to
the
bug!




Here is the proposed release note, please edit, if needed:
------------------------------------------------------------------------
--

Hello Lucene users,

On behalf of the Lucene dev community (a growing community far larger
than
just the committers) I would like to announce the release of Lucene Java
3.0:

The new version is mostly a cleanup release without any new features.
All
deprecations targeted to be removed in version 3.0 were removed. If you
are
upgrading from version 2.9.1 of Lucene, you have to fix all deprecation
warnings in your code base to be able to recompile against this version.

This is the first Lucene release with Java 5 as a minimum requirement.
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 this version for new
developments, because it has a clean, type safe new API. Upgrading users
can
now remove unnecessary casts and add generics to their code, too. If you
have not upgraded your installation to Java 5, please read the file
JRE_VERSION_MIGRATION.txt (please note that this is not related to
Lucene
3.0, it will also happen with any previous release when you upgrade your
Java environment).

Lucene 3.0 has some changes regarding compressed fields: 2.9 already
deprecated compressed fields; support for them was removed now. Lucene
3.0
is still able to read indexes with compressed fields, but as soon as
merges
occur or the index is optimized, all compressed fields are decompressed
and
converted to Field.Store.YES. Because of this, indexes with compressed
fields can suddenly get larger.

While we generally try and maintain full backwards compatibility between
major versions, Lucene 3.0 has some minor breaks, mostly related to
deprecation removal, pointed out in the 'Changes in backwards
compatibility
policy' section of CHANGES.txt. Notable are:

- IndexReader.open(Directory) now opens in read-only mode per default
(this
method was deprecated because of that in 2.9). The same occurs to
IndexSearcher.

- Already started in 2.9, core TokenStreams are now made final to
enforce
the decorator pattern.

- If you interrupt an IndexWriter merge thread, IndexWriter now throws
an
unchecked ThreadInterruptedException that extends RuntimeException and
clears the interrupt status.

------------------------------------------------------------------------
--



Thanks,
Uwe


-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de



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



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




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

Reply via email to