: 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 trunk. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
