您如何决定何时升级项目中的库？

Question

我在使用多个开源Java库的项目上工作。当升级到这些库时，我们倾向于遵循保守的策略：

1. 如果没有破损，请不要修理
2. 如果它没有我们想要的新功能，请忽略它

我们遵循此策略是因为我们通常没有时间放入新库并彻底测试整个应用程序。 （像许多软件开发团队一样，我们总是落后于几个月前承诺的功能。）

但是，我有时想知道这种策略是否明智，因为一些性能改进和大量的bug修复通常伴随着库升级。 （即“谁知道，也许事情会以我们无法预见的方式更好地工作......”）

在项目中做出这些类型的决策时，您使用什么标准？

Answer 1

重要提示：避免使用Technical Debt。

“如果没有损坏，请不要升级”是一个疯狂的政策，导致软件破碎，无人能解决。

皮疹，未经测试的改变是一个坏主意，但没有累积技术债务那么糟糕，因为它在短期内看起来更便宜。

进行“夜间构建”过程，以便您可以持续测试所有更改 - 您的更改以及您所依赖的包。

在您进行持续集成过程之前，您可以执行包含基础架构升级的季度主要版本。

避免技术债务。

Answer 2

我已经吸取了足够的教训来完成以下工作：

1. 检查图书馆的更改列表。他们修复了什么？我关心的？如果没有更改列表，则我的项目中不会使用该库。
2. 人们在图书馆论坛上发帖的内容是什么？在发布后不久就会发现一些帖子，指出明显的问题？
3. 与2号一样，不要立即升级。每个人发布都不好。我不打算成为第一个得到这个小虫子的人。 （再也是）。这并不意味着要等6个月。在发布的第一个月内，你应该知道缺点。
4. 当我决定继续升级时;测试，测试测试。这里的自动化测试非常重要。

编辑：我想再添加一项至少同样重要的项目，也许比其他项目更多。

• 此版本引入了哪些重大变化？换句话说，图书馆是朝着不同的方向发展的吗？如果库正在弃用或替换功能，您将希望保持最佳状态。

Answer 3

一种方法是在您自己的源代码控制下使用您使用的开源库。然后定期将上游更改合并到下一个发布分支中，或者如果它们是安全修复程序，则会更快，并运行自动化测试。

换句话说，使用相同的标准来决定是否像在内部编写的代码一样使用上游更改。考虑开源开发人员加入虚拟开发团队。无论如何，情况确实如此，这只是您是否选择将其视为开发实践的一部分。

Answer 4

虽然您不想仅因为有新版本而升级，但还有另一个考虑因素，即旧版本的可用性。我在尝试构建开源项目时遇到了这个问题。

Answer 5

我通常认为忽略新版本的库（因为它没有任何有趣的功能或改进）是一个错误，因为有一天你会发现这个版本是迁移到您可能希望升级到的下一个版本。

所以我的建议是仔细检查新版本中的变化，并考虑这些变化是否需要大量测试，或者很少。

如果需要进行大量测试，最好在软件的下一个版本（主要版本）升级到较新的库（例如从v8.0升级到v8.5时）。当发生这种情况时，我想还有其他重大修改，因此进行了大量测试。

Answer 6

我不希望版本在依赖库上落后太多。 除非知道安全性或性能问题，否则大多数库可以使用长达一年的时间。 具有已知安全问题的库是必须刷新的。

我会定期下载每个库的最新版本并使用它们运行我的应用程序单元测试。 如果它们通过，我会在我们的开发和集成环境中使用它们一段时间，并在我满意它们不会吮吸时推送到QA。

上述过程假设API没有显着变化。如果我需要重构现有代码只是为了使用更新的库版本，所有的赌注都是关闭的。 （例如Axis 1x vs. 2x）然后我需要让管理层参与决定分配资源。在计划对遗留代码进行重大修订之前，这种更改通常会有所不同。

Answer 7

一些重要问题：

• 图书馆的使用范围有多广？ （如果它被广泛使用，将会更快地找到并消除错误）
• 它是如何积极发展的？
• 文件是否非常清楚？
• 是否有重大变化，次要变更或内部变更？
• 升级是否会破坏向后兼容性？ （您是否需要更改任何代码？）

除非根据上述标准升级看起来不好，否则最好还是使用它，如果有任何问题，请恢复旧版本。