Frameworks 是否应自动将工具/框架/依赖项升级到最新版本？

在我目前的工作中，毫无疑问，如果我们在项目中使用的技术的新版本发布，我们会尽快升级。在我以前的工作中，情况并非如此。。。我们必须让管理层相信这是必要的。因此，我们常常不得不放弃那些本可以帮助我们的功能，继续使用那些早已修复的bug。有时，甚至很难获得对我们正在使用的旧版本的支持。我真的不明白那种观点，尤其是在经历了相反的方法之后。这个问题真的有两个方面吗？

在这两种方法中，我绝对更喜欢你现在的方法。由于许多原因，应用程序落后可能是痛苦的，您注意到了其中一些原因

唯一的警告是围绕时间，真的；为新的框架/依赖项更新某些内容通常需要相当长的时间。框架保持向后兼容性很好，但这并不总是发生

破坏性的变化通常是显而易见的，而且通常（我们希望）存在的原因非常充分。更麻烦的是，无声的改变并不能阻止建筑，但会引起微妙的错误；类似于具有相同签名的库函数，但其行为或返回结果略有不同

---

但是如果一个应用程序需要长期支持，保持它的更新是必须的，IMO.

< P>有一个灰色区域位于中间某个地方。 你的老房子是靠“不要摇摇欲坠”的方式住的。是的，这些东西可能不是最新的，但他们知道它能做什么（也许不能），以及如何处理它。如果有一个问题，你希望知道它不是工具包，因为它是围绕块（或你已经围绕块找出所有的错误，以及如何处理它们，并保持您的工具包运行）

你的新公司将他们所有的信念都放在了一个事实上，那就是新的套件一定会更好，如果没有大量的制衡，就不可能发布。是的，可能有一些怪癖，但是知道一些旧的bug已经不存在了（发布文档说它已经修复了），花时间在最新版本中寻找新的bug是值得的

---

这是一条很好的路线，在很大程度上取决于技术的用途和任务关键性。

是的，这个问题肯定有两个方面。每当发布新版本时，我都会考虑不升级

• 如果它没有坏，就不要修理它。如果您的系统正常工作，则任何 改变是一种风险，并非所有的风险都是 值得一试
• 如果你每次升级一个新的 任何组件的发布都会弹出您的窗口 你会发现自己跟在别人后面 人们的日程安排

---

变更管理对于强健可靠的系统来说至关重要。

您确定升级是唯一的风险吗？也许不升级也是一种风险？@Joel不升级也是一种风险，但它（更多）是一种已知的风险，而升级带来了更多的未知因素。这通常取决于你对出版商的信任程度，他们不会发布有问题的版本。@JoelFan：当然，不升级也可能是一个风险——变更管理的一部分是权衡升级和不升级的风险。