lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: 1.4.3 breaks 1.4.1 QueryParser functionality
Date Wed, 05 Jan 2005 21:12:35 GMT
Hello Bill,

"I feel your pain" ;)
But seriously, there was a QueryParser mess-up in the recent minor
releases.  I think this is the first time we've messed up the backward
compatibility in the last ~4 years, I believe.  Lucene public API is
very 'narrow', and typically very stable.  What we did with QueryParser
was the result of 'overeagerness', but is really out of character for
Lucene.

Otis


--- Bill Janssen <janssen@parc.com> wrote:

> Doug,
> 
> My application (see http://www.parc.com/janssen/pubs/TR-03-16.pdf for
> details) is not just a Java app (you're probably not surprised :-).
> It requires about a dozen other packages to be installed on a
> machine,
> before building from source.  The Python Imaging Library, ReportLab,
> libtiff, libpng, xpdf, htmldoc, etc.  Lucene is one of these
> prerequisites.  I don't include any other outside code with my tar
> file; not sure why Lucene should be the only one to require this.
> 
> Besides, I'd like to keep up with the continuous improvements in
> Lucene.  I don't want to be stuck with 1.4.1 forever.
> 
> Please understand that I'm not trying to push your project in any
> particular direction.  I'm just trying to understand whether Lucene
> is
> usable for my project.  If every micro-release of Lucene means that I
> will potentially have to re-write my code, I may have to look for a
> library with a more stable API.
> 
> Maybe I just misunderstand your release numbering policy.  Typically,
> in a library project that has major, minor, and micro release
> numbers,
> I'd expect no API changes between micro releases of a single minor
> release; only backward-compatible API extensions between different
> minor releases of a single major release; possible wholesale API
> changes (not backward compatible) between different major releases.
> Is this the kind of thinking that you also have?
> 
> I can certainly understand that when you find improvements you'd like
> to make in the API, you'd want to put them in.  I just think it's
> important not to break existing code without bumping the release
> number, so that a user can say, "This works with Lucene 1.4".  Right
> now, that can't be said.
> 
> Bill
> 
> Doug Cutting wrote:
> > Bill, most folks bundle appropriate versions of required jars with
> their 
> > applications to avoid this sort of problem.  How are you deploying 
> > things?  Are you not bundling a compatible version of the lucene
> jar 
> > with each release of your application?  If not, why not?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message