Grokbase › Groups › Lucene › java-user › February 2010
FAQ
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:

- 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4
- 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5.

New users of Lucene are advised to use version 3.0.1 for new developments, because it has a clean, type-safe API.

Important improvements in these releases include:

- An increased maximum number of unique terms in each index segment.
- Fixed experimental CustomScoreQuery to respect per-segment search. This introduced an API change!
- Important fixes to IndexWriter: a commit() thread-safety issue, lost document deletes in near real-time indexing.
- Bugfixes for Contrib's Analyzers package.
- Restoration of some public methods that were lost during deprecation removal.
- The new Attribute-based TokenStream API now works correctly with different class loaders.

Both releases are fully compatible with the corresponding previous versions. We strongly recommend upgrading to 2.9.2 if you are using 2.9.1 or 2.9.0; and to 3.0.1 if you are using 3.0.0.

See core changes at
http://lucene.apache.org/java/3_0_1/changes/Changes.html
http://lucene.apache.org/java/2_9_2/changes/Changes.html

and contrib changes at
http://lucene.apache.org/java/3_0_1/changes/Contrib-Changes.html
http://lucene.apache.org/java/2_9_2/changes/Contrib-Changes.html

Binary and source distributions are available at
http://www.apache.org/dyn/closer.cgi/lucene/java/

Lucene artifacts are also available in the Maven2 repository at
http://repo1.maven.org/maven2/org/apache/lucene/

-----
Uwe Schindler
[email protected]
Apache Lucene Java Committer
Bremen, Germany
http://lucene.apache.org/java/docs/



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Search Discussions

  • Paul Taylor at Feb 26, 2010 at 10:13 am ⇧

    Uwe Schindler wrote:
    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:

    - 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java 1.4
    - 3.0.1 has the same bug fix level but is for the Lucene Java 3.x series, based on Java 5.
    Hmm , I don't really agree with deprecating Version.LUCENE_CURRENT (
    http://issues.apache.org/jira/browse/LUCENE-2080)

    I'm sure in many projects, especially ones that are not yet released
    developers would expect to pick up the latest features when they
    download the latest version of Lucene without having to update the value
    of the Version constant (its just make devlopment a bit more tiresome)
    and would realize that code should be rebuilt and indexes should be
    built with same version as searching indexes. I mean whenever you update
    the version of a library should really test your code, after all Lucene
    3.0.0 changed some things in 2.9.2 unwittingly, hence the need for 3.0.1.

    Paul




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
  • Robert Muir at Feb 26, 2010 at 10:24 am ⇧
    such projects can do this, in one place:

    public static final Version MY_APP_CURRENT = Version.LUCENE_30;

    then later....

    StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);

    then they have complete control of this, independent of when the upgrade
    lucene's jar file!
    On Fri, Feb 26, 2010 at 5:12 AM, Paul Taylor wrote:

    Uwe Schindler wrote:
    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:

    - 2.9.2 is a bugfix release for the Lucene Java 2.x series, based on Java
    1.4 - 3.0.1 has the same bug fix level but is for the Lucene Java 3.x
    series, based on Java 5.
    Hmm , I don't really agree with deprecating Version.LUCENE_CURRENT (
    http://issues.apache.org/jira/browse/LUCENE-2080)

    I'm sure in many projects, especially ones that are not yet released
    developers would expect to pick up the latest features when they download
    the latest version of Lucene without having to update the value of the
    Version constant (its just make devlopment a bit more tiresome) and would
    realize that code should be rebuilt and indexes should be built with same
    version as searching indexes. I mean whenever you update the version of a
    library should really test your code, after all Lucene 3.0.0 changed some
    things in 2.9.2 unwittingly, hence the need for 3.0.1.

    Paul




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]

    --
    Robert Muir
    [email protected]
  • Paul Taylor at Feb 26, 2010 at 10:27 am ⇧

    Robert Muir wrote:
    such projects can do this, in one place:

    public static final Version MY_APP_CURRENT = Version.LUCENE_30;

    then later....

    StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);

    then they have complete control of this, independent of when the
    upgrade lucene's jar file!
    Not quite true because you still need to update MY_APP_CURRENT when
    there is a new version, but yes thats more mangeable

    Paul

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
  • Johannes Zillmann at Feb 26, 2010 at 10:43 am ⇧
    Just one thought...

    For me it would be natural to be never confronted with the Version.xx thing in the api unless you really need.
    so f.e. having
    new QueryParser("", new KeywordAnalyzer()).parse("content: the");
    as a default (probably using Version.LUCENE_CURRENT under the hood), but having
    new QueryParser(Version.XXX,"", new KeywordAnalyzer()).parse("content: the");
    as well.

    Of cause this would require a lot of method/constructor overloading, but would make the api more user friendly for those who write some code where the version don't matter...
    Johannes
    On Feb 26, 2010, at 11:27 AM, Paul Taylor wrote:

    Robert Muir wrote:
    such projects can do this, in one place:

    public static final Version MY_APP_CURRENT = Version.LUCENE_30;

    then later....

    StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);

    then they have complete control of this, independent of when the upgrade lucene's jar file!
    Not quite true because you still need to update MY_APP_CURRENT when there is a new version, but yes thats more mangeable

    Paul

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
  • Michael McCandless at Feb 26, 2010 at 10:50 am ⇧
    That would be more natural/convenient, but it'd unfortunately defeat
    the whole reason Version was added in the first place.

    By making Version required, we force callers to be explicit to Lucene
    about what level of back compat is required.

    This then enables Lucene to improve its defaults with each release,
    without breaking users that need to keep backwards compatibility.

    Mike

    On Fri, Feb 26, 2010 at 5:42 AM, Johannes Zillmann
    wrote:
    Just one thought...

    For me it would be natural to be never confronted with the Version.xx thing in the api unless you really need.
    so f.e. having
    new QueryParser("", new KeywordAnalyzer()).parse("content: the");
    as a default (probably using Version.LUCENE_CURRENT under the hood), but having
    new QueryParser(Version.XXX,"", new KeywordAnalyzer()).parse("content: the");
    as well.

    Of cause this would require a lot of method/constructor overloading, but would make the api more user friendly for those who write some code where the version don't matter...
    Johannes
    On Feb 26, 2010, at 11:27 AM, Paul Taylor wrote:

    Robert Muir wrote:
    such projects can do this, in one place:

    public static final Version MY_APP_CURRENT = Version.LUCENE_30;

    then later....

    StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);

    then they have complete control of this, independent of when the upgrade lucene's jar file!
    Not quite true because you still need to update MY_APP_CURRENT when there is a new version, but yes thats more mangeable

    Paul

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
  • Ian Lea at Feb 26, 2010 at 12:17 pm ⇧
    Could there be a Version value called
    LUCENE_LATEST_DANGER_USE_AT_YOUR_OWN_RISK or whatever you want to make
    it.

    I understand the argument about backwards compatibility but I'm with
    Johannes on making things easier for those who have code which doesn't
    require the compatibility. Like me. I've been using lucene since the
    very beginning and don't recall ever having been bitten by any back
    compatibility problems (another reason for praise for the committers)
    and would rather not have to start changing literals on upgrades.

    Is the plan to remove LUCENE_CURRENT altogether or to leave it in,
    permanently deprecated?
    If the latter we could carry on using it although living with
    deprecations isn't great.


    Doing simple things in lucene does in general seem to be getting
    harder. Off the top of my head ...

    IndexSearcher s = new IndexSearcher("/my/index");
    QueryParser qp = new QueryParser("", new StandardAnalyzer());
    Query q = qp.parse("field: value");
    Hits h = s.search(q);
    for (int i = 0; i < h.length; i++) {
    System.out.println(h.doc(i).get("field"));
    }

    used to work. It won't now of course, and I'd have to look at the
    javadocs to come up with alternatives.

    Keep APIs simple!



    --
    Ian.


    On Fri, Feb 26, 2010 at 10:50 AM, Michael McCandless
    wrote:
    That would be more natural/convenient, but it'd unfortunately defeat
    the whole reason Version was added in the first place.

    By making Version required, we force callers to be explicit to Lucene
    about what level of back compat is required.

    This then enables Lucene to improve its defaults with each release,
    without breaking users that need to keep backwards compatibility.

    Mike

    On Fri, Feb 26, 2010 at 5:42 AM, Johannes Zillmann
    wrote:
    Just one thought...

    For me it would be natural to be never confronted with the Version.xx thing in the api unless you really need.
    so f.e. having
    new QueryParser("", new KeywordAnalyzer()).parse("content: the");
    as a default (probably using Version.LUCENE_CURRENT under the hood), but having
    new QueryParser(Version.XXX,"", new KeywordAnalyzer()).parse("content: the");
    as well.

    Of cause this would require a lot of method/constructor overloading, but would make the api more user friendly for those who write some code where the version don't matter...
    Johannes
    On Feb 26, 2010, at 11:27 AM, Paul Taylor wrote:

    Robert Muir wrote:
    such projects can do this, in one place:

    public static final Version MY_APP_CURRENT = Version.LUCENE_30;

    then later....

    StandardAnalyzer analyzer = new StandardAnalyzer(MY_APP_CURRENT);

    then they have complete control of this, independent of when the upgrade lucene's jar file!
    Not quite true because you still need to update MY_APP_CURRENT when there is a new version, but yes thats more mangeable

    Paul

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]

    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: [email protected]
    For additional commands, e-mail: [email protected]

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupjava-user @
categorieslucene
postedFeb 26, '10 at 8:17a
activeFeb 26, '10 at 12:17p
posts7
users6
websitelucene.apache.org

6 users in discussion

Paul Taylor: 2 posts Robert Muir: 1 post Ian Lea: 1 post Johannes Zillmann: 1 post Uwe Schindler: 1 post Michael McCandless: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase