我们在项目中使用了很多第三方组件。似乎我们不断收到关于某某组件发布了新版本的电子邮件通知。对于何时合并新版本，我们总是在团队中遇到难题。
一方面我们知道
但另一方面
我们想为此制定一项一般政策。例如，一个可能的策略可能是
一旦升级出来， 等待 X 时间，然后 合并新版本， 不管发生了什么 项目或我们是否需要任何新的 功能或修复
或者……
忽略所有这些升级电子邮件和 如果您需要新功能，只需升级 或修复
或者……
等到一个自然的慢点 发展（无论是什么）然后 将所有内容升级到最新 版本
或者... ???
有没有关于这个主题的研究或指南？
【问题讨论】：
标签： language-agnostic components
有没有关于这个主题的研究或指南？
是的。问 12 位经理，你会得到 18 条意见。
“一旦升级出来，等待 X 时间，然后合并新版本，不管项目中发生了什么，或者我们是否需要任何新功能或修复”。
不假思索地遵守时间表。总是个好主意。
“忽略所有这些升级电子邮件，如果您需要新功能或修复，只需升级”
“忽略”？如果您“忽略”通知，您将如何决定“是否需要新功能或修复”？
我必须假设“忽略”并不意味着“忽略”而是意味着其他东西。
“等到开发的自然缓慢点（无论是什么），然后将所有内容升级到最新版本”
不假思索地遵守时间表。还是个好主意。
这是底线。
您必须真正考虑升级及其含义。
安全性？高优先级。您可能想停止开发，对此进行测试，然后立即投入使用。
错误修复？高优先级。你一直在等待这个。当然，您可以停止开发、安装它并立即享受好处。
随机升级？低优先级。实际上，您可以在开发人员和产品所有者之间讨论，以决定是现在还是以后。
不可能有一个简单的规则，因为升级有很多不同类型，升级会以多种不同方式影响您交付的内容。
【讨论】：
一个经验法则是避免在发布或迭代接近尾声时更新第三方组件——除非有非常好的理由例外。
如您所见，更新第三方组件会带来额外成本。 它还会带来额外的风险。随着您接近发货日期，可接受的风险水平会降低。
正如 S. Lott 所提到的，有时也有例外。安全更新、错误修复和增强功能可能对您的产品很重要——也可能不重要。
【讨论】：