我正在研究一个我不认识的人正在使用的项目。我们在降低CheckStyle警告方面做得相当不错，而且在没有破坏二进制兼容性的情况下，它的价格很低。
大多数剩余警告是由常量（public static final）错过最终关键字引起的。常量的命名清楚地表明开发人员希望它们只读，但它们根本没有最终定义。
除非开发人员编写了一些使用此疏忽的非常糟糕的代码，否则如果我们添加它们，代码就不会破坏。
目前版本号为1.2.1。您是否应用更改并转到2.0，或应用它并将其推出为1.3。似乎是一个非常小的变化，需要一个完整的2.0。
我该怎么办？
答案 0 :(得分：4)
在我看来，应该暂停这样可能破坏二进制兼容性的更改，直到主要版本发布。也就是说，您的问题不应该是“我应该使用什么版本号”，而是“何时应该进行这些更改”。
如果您完全致力于二进制兼容性，那么您应该推迟这些更改，直到包含重大改进的版本证明升级成本合理。例如，KDE项目对主要版本强加了二进制兼容性要求。这意味着在该版本的生命周期内的任何改进都不能破坏针对旧版本编译的应用程序。因此，希望清理代码的开发人员必须等到下一个主要版本。
一旦你准备发布一个包含所有漂亮新功能的主要版本，请继续进行你认为必要的二进制兼容性更改，在这种情况下，如果出现问题则不会令人感到意外。
如果你想要聪明，你可以实现一个预处理器并编译代码两次，一次使用韵母，一次不使用。这可以作为真正决赛的垫脚石，但同时维护成本也会很高。
答案 1 :(得分：3)
我相信你已经知道了这一点，但我怀疑它必须归结为“这是一个安全/简单/无忧”升级吗？
我认为这还取决于您与下一个主要版本的发布有多接近。如果很快，不要冒险出现问题点。你总是可以做一个安全的点发布和一个alpha主要版本，但是如果下一个主要版本在将来出现的话，这可能会很奇怪......
答案 2 :(得分：2)
我说打破他们。如果你是一个变异的静态，那么你必须知道你做错了。但是，您可能希望将其分成不同的版本，以便客户端有机会（无论是否接受它们）顺利升级，而不是因为需要其他无关的修复而陷入恐慌。
答案 3 :(得分：0)
除非开发人员编写了一些使用此疏忽的非常糟糕的代码，否则如果我们添加它们，代码就不会破坏。
就像创建以前非终结类的子类一样，它们将不再起作用吗？
我认为它应该是2.0并且您应该继续支持1.x系列
此外，还有一个关于API的有趣视频：Joshua Bloch创建者的“How to design a good API and why it matters”，以及Java中的核心库，现在正在Google上工作