您如何决定何时升级项目中的库？
我正在开发一个使用多个开源Java库的项目。 当升级到这些库时，我们倾向于遵循保守的策略：
- 如果没有破损，请不要修理它
- 如果它没有我们想要的新function，请忽略它
我们遵循这一策略是因为我们通常没有时间放入新库并彻底测试整个应用程序。 （像许多软件开发团队一样，我们总是落后于几个月前承诺的function。）
但是，我有时想知道这种策略是否明智，因为一些性能改进和大量的bug修复通常伴随着库升级。 （即“谁知道，也许事情会以我们无法预见的方式更好地运作……”）
在项目中做出这些类型的决策时，您使用什么标准？
我已经吸取了足够的教训来完成以下工作：
- 检查库的更改列表。 他们修复了什么？ 我关心的？ 如果没有更改列表，则我的项目中不使用该库。
- 人们在图书馆论坛上发帖的是什么？ 发布后不久就开始发布一系列post，指出明显的问题？
- 与2号一样，不要立即升级。 每个人发布都不好。 我不打算成为第一个得到这个小虫子的人。 （不再是）。 这并不意味着要等6个月。 在发布的第一个月内，您应该知道缺点。
- 当我决定继续升级时; 测试，测试测试。 这里的自动化测试非常重要。
编辑：我想添加一个至少同样重要的项目，也许比其他项目更重要。
- 这个版本引入了哪些重大变化？ 换句话说，图书馆是否朝不同的方向发展？ 如果库正在弃用或替换function，您将希望保持最佳状态。
重要提示：避免技术债务 。
“如果它没有破产，不要升级”是一个疯狂的政策，导致软件如此破碎，没有人可以解决它。
皮疹，未经测试的改变是一个坏主意，但并不像累积技术债务那么糟糕，因为它在短期内看起来更便宜。
获得“夜间构建”过程，以便您可以持续测试所有更改 – 您的更改以及您依赖的包。
在您进行持续集成过程之前，您可以执行包含基础架构升级的季度主要版本。
避免技术债务。
一种方法是在您自己的源代码控制下使用您使用的开源库。 然后定期将上游更改合并到您的下一个版本分支中，或者如果它们是安全修复程序则更快，并运行您的自动化测试。
换句话说，使用相同的标准来决定是否像在内部编写的代码一样使用上游更改。 考虑开源开发人员成为虚拟开发团队的一员。 无论如何，情况确实如此，只是您是否选择将其视为开发实践的一部分。
虽然您不想因为有新版本而需要升级，但还有另一个考虑因素，即旧版本的可用性。 我遇到了试图构建开源项目的问题。
我通常认为忽略一个新版本的库（因为它没有任何有趣的function或改进）是一个错误，因为有一天你会发现这个版本是迁移到下一个版本所必需的。你可能想要升级到。
所以我的建议是仔细审查新版本中的变化，并考虑变更是否需要大量测试，或者很少。
如果需要进行大量测试，最好在软件的下一个版本（主要版本）升级到更新的库（例如从v8.0升级到v8.5时）。 当发生这种情况时，我想还有其他重大修改，因此进行了大量测试。
我不想让版本在依赖库上落后太多。 除非知道安全性或性能问题，否则大多数库可以使用长达一年的时间。 具有已知安全问题的库是必须刷新的。
我会定期下载每个库的最新版本并使用它们运行我的应用程序unit testing。 如果它们通过，我会在我们的开发和集成环境中使用它们一段时间，并在我满意它们没有吮吸时推送到QA。
上述过程假设API没有显着变化。 如果我需要重构现有代码只是为了使用更新的库版本，所有的赌注都会被取消。 （例如Axis 1x vs. 2x）然后我需要让管理层参与决定分配资源。 在计划对遗留代码进行重大修订之前，这种更改通常会有所不同。
一些重要问题：
- 图书馆有多广泛使用？ （如果它被广泛使用，将更快地找到并消除错误）
- 它是如何积极发展的？
- 文件是否非常清楚？
- 是否有重大变化，次要变更或内部变更？
- 升级是否会破坏向后兼容性？ （你需要改变你的任何代码吗？）
除非根据上述标准升级看起来不好，否则最好使用它，如果遇到任何问题，请恢复旧版本。