I'm not a lawyer, so I dislike trying to nail down every detail in writing and try to solve future problems in the abstract.
Lucene has never really been 100% back compatible... we've just tried to keep it that way... it's more of a mindset than a reality, and I'm wary of changing that mindset too much. Lucene has benefited from API and design stability, and I think the bar should be kept high for changes (i.e. there should be clear benefits). Anyway, I think substantially relaxing back compat requirements is enough of a change that it should at some point go to a vote (once people figure out exactly what is being voted on ;-) That doesn't apply to a static actsAsVersion that would preserve back compatibility by default of course. > 3. Default settings can change, but if the change is big enough (and > certainly if it will impact what's indexed or how searches find > docs/do scoring), we add a required "actsAsVersion" arg to the > ctor of the affected class. New users get the latest & greatest, > and upgraded users keep their old defaults. If we get to the point of passing something around, it might as well be a Settings object, unless it's an inner loop efficiency thing. Depending on the specifics, it may often be simpler/cleaner to create a new class / constructor and deprecate the old, as we do now. > 4. [Maybe?] Allow certain limited changes that will require source > code changes in your app on upgrading to a new minor release: > adding a new method to an interface, adding a new abstract method > to an abstract class, renaming of deprecated methods. +1, depending on the specifics. This is where back compat rules shouldn't be cast in stone. There are some public classes in Lucene that are really just implementation artifacts - pretty much no one will directly use those classes and changes to those shouldn't be a big deal. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
