That brings us back to an earlier discussion: "if majority want to
break compatibility, then we should do so, and the minority can back-
port the changes to a previous release if they feel it is warranted."
I don't understand why that isn't a viable approach.
I agree that maintaining interface compatibility through versions is
a great ideal, but when the API becomes so bloated (deprecated
methods, and even usage patterns), it is much harder to learn, and
use properly.
Look at similar problems and how they handled in the JDK. The Date
class has been notorious since its inception. The Calendar class is
almost no better, now they are developing JSR-310 to replace both.
Existing code can still use the Date or Calendar classes. Both they
don't get any "newer" features. This would be similar to use the old
lucene jar.
On Jan 18, 2008, at 12:31 AM, Karl Wettin wrote:
18 jan 2008 kl. 03.39 skrev Grant Ingersoll:
Does anyone have experience w/ how other open source projects deal
with this?
Would be a pain to implement, but it could be done as libcompat.
lucene-2.4-compat-core-3.0.jar
--
karl
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
