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 <paul_t...@fastmail.fm> 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: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > > -- Robert Muir rcm...@gmail.com
