清理代码破坏了二进制兼容性

Question

我正在从事一个我不认识的人正在使用的项目。在降低CheckStyle警告方面，我们做得相当不错，并且在不破坏二进制兼容性的前提下，它的价值很低。

剩余的大多数警告是由缺少final关键字的常量（公共静态final）引起的。常量的命名清楚地表明，开发人员希望它们是只读的，但是它们根本没有最终定义。

除非开发人员使用这种疏忽编写了一些非常糟糕的代码，否则如果我们添加它们，它们的代码将不会中断。

当前版本号是1.2.1。您将应用更改并转到2.0，还是将其应用并以1.3发布。似乎是很小的更改，需要完整的2.0。

我该怎么办？

Answer 1

我确定您已经知道这一点，但是我怀疑它必须归结为“这是安全/简单/不用担心”的升级吗？

• 点发布被认为是安全且常规的。它们应该完全由某些项目中的错误修复组成。如果其他项目不太可能引起问题，它们将包含新功能。
• 新的主要版本发布包含可能需要适应的进化变化
• 新的主要[[x.0版本版本被老练用户高度怀疑：-）

我认为这还取决于您与下一个主要版本之间的距离。如果很快，不要冒险发布问题。您始终可以进行安全点发布和Alpha主版本，但是如果下一个主版本将来会淘汰，这可能很奇怪...

Answer 2

我认为，这样的更改可能会破坏二进制兼容性，直到发布主要版本之前，才应推迟这样做。也就是说，您的问题不应该是“我应该使用哪个版本号”，而应该是“我何时应该进行这些更改”。

如果您完全致力于二进制兼容性，则应推迟这些更改，直到发布包含重大改进以证明升级成本合理的版本为止。例如，KDE项目对主要版本提出了二进制兼容性要求。这意味着在该发行版生命周期内的任何改进都不会破坏针对旧版本编译的应用程序。因此，希望清理代码的开发人员必须等到下一个主要版本。

一旦准备好发布具有所有出色新功能的主要版本，继续进行您认为必要的二进制兼容性更改，在这种情况下，如果出现问题，就不足为奇了。

如果您想变得聪明，可以实现一个预处理器并编译两次代码，一次使用final，一次不使用。这可以用作迈向真正决赛的垫脚石，但与此同时维护成本也很高。

Answer 3

我说打碎他们。如果您是变异静态对象，那么您必须知道自己做错了。但是，您可能希望将其分为不同的发行版，以便客户端（无论是否接受）有机会顺利升级，而不是因为他们需要一些其他不相关的修复程序而慌乱地升级。

Answer 4

除非开发人员使用这种疏忽编写了一些非常糟糕的代码，否则，如果我们添加它们，它们的代码将不会中断。

就像创建以前将不再起作用的非最终类的子类一样？

我认为应该是2.0，并且您应该继续支持1.x系列

另外，还有一段关于API的有趣视频：Joshua Bloch的创建者“ How to design a good API and why it matters”，所以Java的核心库现在可以在Google上工作