2

我正在做一个被我不认识的人使用的项目。我们在降低 CheckStyle 警告方面做得相当不错，而且在不破坏二进制兼容性的情况下，它会达到一个低水平。

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

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

当前版本号为 1.2.1。您会应用更改并转到 2.0，还是应用更改并将其作为 1.3 推出。需要完整的 2.0 似乎是一个很小的变化。

我该怎么办？

4

4 回答 4

4

在我看来，像这样可能破坏二进制兼容性的更改应该推迟到主要版本发布。也就是说，您的问题不应该是“我应该使用什么版本号”，而应该是“我应该什么时候进行这些更改”。

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

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

如果你想聪明一点，你可以实现一个预处理器并编译代码两次，一次有final，一次没有。这可以作为真正决赛的垫脚石，但同时维护成本会很高。

于 2009-10-19T19:44:01.130 回答
3

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

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

我认为这还取决于您与下一个主要版本发布的距离。如果它很快，不要冒险发布有问题的点。你总是可以做一个安全点发布和一个 alpha 主要版本，但如果下一个主要版本在未来出现，这可能会很奇怪......

于 2009-10-19T19:27:41.040 回答
2

我说打破他们。如果你是一个变异的静态人，那么你必须知道你做错了。但是，您可能希望将其分离到不同的版本中，以便客户有机会（无论他们是否接受）顺利升级，而不是因为需要其他一些不相关的修复而惊慌失措。

于 2009-10-19T19:35:59.543 回答
0

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

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

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

此外，这里有一个关于 API 的有趣视频：“如何设计一个好的 API 及其重要性”，作者 Joshua Bloch 创建了 Java 中的核心库，现在在谷歌工作

于 2009-10-19T19:29:30.180 回答