lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Date Thu, 22 Jun 2006 22:06:37 GMT

: If 2.1 will break API compatibility then it should be called 3.0.  Major
: release numbers are all about API compatibility.  If code works with
: Lucene X.Y, then it should also compile against Lucene X.Y+1, but it may
: not work with Lucene X+1.Z.

: JVM version is orthogonal to this, no?

One could argue that the JVM Lucene can run in is the most important API
of the jar ... if lucene-core-2.0.jar can run in a java1.4 JVM, and
lucene-core-2.1.jar doesn't then I would consider that at least as serious
of an API compatability change as removing a heavily used public method.

Put another way, if I have a class Foo which can currently compile against
Lucene 2.0 in my java1.4 JVM, then I think it is an API change if an Foo
doesn't compile against Lucene 2.1 in that same java1.4 JVM.

But this strikes me as a symantec issue ... if API changes require reving
the major version number, then a descision to allow java1.5 in the trunk
requires that the next release from the trunk be 3.X (not 2.1) but it
neither procludes nor implies that 1.5 should or shouldn't be used on the


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message