译自：http://wiki.apache.org/lucene-java/BackwardsCompatibility
Lucene的版本号决定了向后兼容性的细节。
次版本号Lucene版本之间对所有公开支持的（public和protected）API完全向后兼容。也就是说，基于X.0版本Lucene开发的代码，只要只使用公开支持的API，那么就可以完全不经修改和重新编译，而用于X.N版本Lucene下（仅需使用新的JAR文件）。
主要版本升级可能引入不兼容的API变化。过渡策略是在X.N版本引入新的API，把老的API标记为废弃，然后在X+1.0版本移除全部废弃的API。
包内的私有代码（没有public或者protected修饰符的方法）不被支持，因而没有任何向后兼容需求。它们可能会在不经警告和讨论的前提下修改。
文件格式在主版本间保持向后兼容。X.N版本应该可以读取X-1.0版本及更新的版本生成的索引，但可能或者可能不能读取X-2.N版本生成的索引。
注意：老版本的Lucene不能保证能够打开新版本Lucene生成的索引。这么做的时候，会产生一个可预期的错误。
一次又一次，Lucene开发者可能决定一个特定的bug修正或者改善，是否在某些Lucene功能中改变默认的运行期间行为，因为“新”行为可能比已有行为“更好”，或者更“正确”。这些改变无需保持向后兼容性，虽然某些Lucene客户端可能依靠或者希望这些“老”行为。
如果发行版内包含一个运行期间行为改变，那么会在CHANGES.txt文件内清晰的标明。
如果运行期间行为改变出现在次版本升级之间（例如X.N到X.N+1），那么有两种机制可以用于“强制使用”老行为：
1. 客户端可以设置JVM系统属性。（这将允许客户程序不修改任何代码就强制使用老行为）
2. 引入静态方法，允许客户程序调用设置一些内部状态优先级。（这将允许那些没有权限修改系统属性的客户程序，用一行代码就可以强制老的行为）
“所有外部包并非生来平等。”
外部包的兼容性目标由它自己的发展阶段和用法决定。每个外部包的README.txt文件应该说明它的兼容性目标。如果README.txt文件没有明确指出向后兼容，用户应该假定它承诺任何向后兼容义务。
所属分类:
[lucene]
[Java]
tag：
兼容性,
向后兼容,
tinyfool发布于2009年10月03日 10:45
最后更新于2009年10月14日 15:19