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

我从事一个使用多个开源Java库的项目。当对这些库进行升级时，我们倾向于采用保守的策略：

如果它没有坏，就不要修理它

如果它没有我们想要的新功能，请忽略它

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

但是，考虑到库升级通常会带来一些性能改进和大量错误修复，我有时怀疑这种策略是否明智。（也就是说，“谁知道，也许事情会以我们无法预见的方式变得更好……”

---

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

我学到了足够的经验，可以做以下几点：

检查库的更改列表。他们修好了什么？我在乎吗？如果没有更改列表，则库不会在我的项目中使用

人们在图书馆的论坛上发布了什么？发布后不久，是否有大量的帖子指出了明显的问题

与2号相同，不要立即升级。每个人都有一个糟糕的释放。我不想成为第一个被那个小虫子咬的人。（不再是这样了）。这也不意味着要等6个月。在发布的第一个月内，您应该知道其缺点

当我决定进行升级时；测试，测试。在这里，自动化测试非常重要

编辑：我想再添加一个项目，它至少和其他项目一样重要，而且可能比其他项目更重要

• 此版本中引入了哪些突破性的更改？换句话说，图书馆是否朝着不同的方向发展？如果库正在弃用或替换功能，您将希望保持最新状态

重要提示：避免

“如果它没有坏，就不要升级”是一个疯狂的政策，它导致软件如此坏以至于没有人能修复它

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

启动“夜间构建”过程，这样您就可以持续测试所有更改——您的更改以及您所依赖的包

在具备持续集成流程之前，您可以每季度发布一次主要版本，包括基础架构升级

---

避免技术债务。

一些重要问题：

• 图书馆的使用范围有多广？（如果广泛使用，将更快地发现并消除bug）
• 它的发展有多积极
• 文件很清楚吗
• 有没有大的变化，小的变化，还是仅仅是内部变化
• 升级是否破坏了向后兼容性？（您是否需要更改任何代码？）

---

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

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

---

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

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

我通常认为忽略一个库的新版本（因为它没有任何有趣的特性或改进）是一个错误，因为有一天你会发现这个版本对于迁移到下一个你可能想要升级的版本是必要的

因此，我的建议是仔细审查新版本中发生了什么变化，并考虑这些变化是否需要大量的测试，或者很少。

---

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

我不希望版本在依赖库上落后太多。 除非已知安全性或性能问题，否则对大多数库来说最多一年是可以的。 必须刷新存在已知安全问题的库。

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

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

1的一个问题是，您可能不知道有些东西坏了，您需要修复它（尤其是安全问题）。