Simon Willnauer <simon.willna...@googlemail.com> wrote: > On Fri, Sep 17, 2010 at 8:14 PM, Bill Janssen <jans...@parc.com> wrote: > > Simon Willnauer <simon.willna...@googlemail.com> wrote: > > > >> Hey Bill, > >> let me clarify what Version is used for since I think that caused > >> little confusion. > > > > Thanks. > > > >> The Version constant was mainly introduced to help > >> users with backwards compatibility and upgrading their codebase to a > >> new version of lucene without breaking existing applications / indexes > >> build with previous versions. For instance StandardAnalyzer preserves > >> the positionIncrement in its StopFilter which was introduces in Lucene > >> 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app > >> since you indexed with a 2.4 behavior. You phrasequeries might not > >> work as expected anymore. If you don't have any upgrade issues or if > >> you can simply reindex you might just use the latest version. > > > > That's what I'm trying to do. But how? LUCENE_CURRENT is deprecated! > > > > How about adding a constructor for StandardAnalyzer that takes no > > parameters and is implicitly LUCENE_CURRENT? > > We deprecated LUCENE_CURRENT for a good reason that is that folks will > run into big trouble if they upgrade from X to X+n because behavior > may change dramatically due to optimizations, bug fixes and useful > features. If you blindly pass LUCENE_CURRENT you might end up with > incompatible APIs in some cases (we do deploy "sophisticated backwards > layers" like we did in CharTokenizer) or query analysis which will not > work with you existing Version X index.
Yes, but that's not an issue if I don't *have* existing version X indices, which I don't. > What you should do is pick YOUR latest version manually and go through > the changes once you upgrade. Write unittests for you API to make sure > it does not break you code. Its worth the trouble! Simon, this advice isn't helping. I have unittests, and, yes, they are worth the trouble. I always re-index my collection if I change to a different version of Lucene. So I'd like to make my choice of the value of org.apache.lucene.util.Version automatically, using tools, instead of choosing it manually, based on what version of Lucene the user has installed, and without encoding a limited set of strings in my application. How do I do that? More directly, is there any attribute or static method somewhere in Lucene which will return a value of org.apache.lucene.util.Version that corresponds to the version of the code? That's what I'm looking for. Version.LUCENE_CURRENT looks good, but it's deprecated. Or, is there a method which will take a Lucene version, expressed as a Package or perhaps even a string like "3.0.2", and return the appropriate Version value? If so, I could write my own code to retrieve the Lucene version, then call that method to retrieve the Version value. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
