Language agnostic 何时升级第三方组件

我们在项目中使用了相当多的第三方组件。似乎我们不断收到电子邮件通知，某某组件发布了新版本。关于何时合并新版本，我们在团队中总是面临一个难题

我们一方面知道这一点

• 从一个版本升级到下一个版本比跳过版本和更新更容易
• 当您需要请求支持时，最好使用最新版本

但另一方面

• 进行这些升级需要时间——开发、QA回归测试、部署等，而在这段时间内，我们并没有开发自己的特性

我们希望就此制定一项总体政策。例如，一个可能的策略可以是

升级一出来,， 等待X时间，然后 纳入新版本,， 不管世界上发生了什么 项目或我们是否需要任何新的 功能或修复

或者

忽略所有升级电子邮件和 如果需要新功能，只需升级即可 或修复

或者

等待，直到一个自然的缓慢点 发展（不管是什么）那么 将所有内容升级到最新版本 版本

还是

关于这个话题有什么研究或指导方针吗

关于这个话题有什么研究或指导方针吗

对。询问12位经理，你会得到18种意见

“一旦升级出来，等待X时间，然后合并新版本，不管项目中还有什么其他情况，也不管我们是否需要任何新功能或修复”

不假思索地遵守时间表。总是个好主意

“忽略所有升级电子邮件，如果需要新功能或修复程序，只需升级即可”

“忽略”？如果“忽略”通知，您将如何决定“是否需要新功能或修复”

我必须假设“忽略”并不意味着“忽略”，而是意味着其他东西

“等到开发过程中出现自然的缓慢点（不管是什么），然后将所有内容升级到最新版本”

不假思索地遵守时间表。还是个好主意

这是底线

实际上，你必须思考升级及其意义

• 保安？高度优先。您可能想停止开发，测试它，并立即投入使用

• Bug修复？高度优先。你一直在等这个。当然，您可以停止开发，安装它，并立即享受其好处

• 随机升级？低优先级。实际上，您可能会在开发人员和产品所有者之间讨论这个问题，以决定是现在还是以后使用它

---

不可能有一个简单的规则，因为有这么多不同类型的升级，升级会以这么多不同的方式影响您的交付。

一个经验法则是避免在发布或迭代结束时更新第三方组件，除非有非常好的理由破例

正如您所注意到的，更新第三方组件会带来额外的成本。它还带来了额外的风险。随着装运日期的临近，可接受的风险水平会降低

正如S.洛特提到的，有时也有例外。安全更新、bug修复和增强可能对您的产品很重要，也可能不重要