So, iterating on the proposed changes to back-compat policy:
1. If we deprecate an API in the 2.1 release, we can remove it in
the next minor release (2.2).
2. JAR drop-in-ability is only guaranteed on point releases (2.4.1
is a drop-in replacement to 2.4.0). When switching to a new
minor release (2.1 -> 2.2) likely you'll need to recompile.
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.
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.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
