使用所有依赖项升级rails版本的最佳做法是什么？

Question

每当发生一些主要的rails版本碰撞时，有时真的很难升级现有的rails应用程序（4.x，5.x等），因为有很多宝石可能依赖于旧版本的rails（ActiveRecord，ActionController，ActiveModel，等等。）。而那些依赖宝石有时需要花费太多时间进行升级（要么不维护，要么不活跃，要么不具备核心维护团队，即使是接受Pull请求）。人们周围的解决方案是什么？

人们建议的一个工作流程是分叉所有依赖的宝石，然后改变你喜欢的任何东西，并不断更新它们各自的主/主分支。我很想听听人们在他们的工作流程中遵循的内容。

Answer 1

我认为你应该删除/替换在主要Rails更新后不久可用的兼容版本的宝石。

在Rails 5发布之前差不多6个月就可以使用测试版的Rails 5。如果gem在该时间内没有更新，它可能不会在以后更新，或者它也会减慢对其他所有Rails更新的影响。

遇到这种情况时，我会看到几个选项：

• 重新审视您使用该宝石的原因。有时你会使用gem来做一些简单的方法。在您的应用程序（或您自己的gem）中重写这些方法并删除此依赖项。
• 是否有其他项目可以解决同样的问题？有时这些项目甚至有更好的结构或其他好处。您可以考虑切换到那些宝石。希望你封装了旧的gem并且没有过多地定制那个gem，因为这使得更换它变得更加困难。
• 您可能会考虑将该宝石分叉并自行解决问题（向原始宝石发送拉动请求的奖励积分）。这在短期内是一个好的解决方案。但是你会非常喜欢与下一个Ruby版本的这个gem有类似的问题。此外，当您使用分叉版本的宝石时，您可以独立完成。你真的想在接下来的几年中维护那个私人宝石版吗？

随着您添加到堆栈中的每个gem，您的应用程序都会产生成本和风险。观看宝石的成本，它是如何变化的，是否有安全修复？以及宝石将在某个时候被抛弃的风险。

当你遇到这样的情况时，你可以预先做一些事情来减轻痛苦：

• 当您只需要一些来自该gem的简单帮助方法时，避免向您的应用程序添加gem。
• 用您自己的包装器封装该gem。并为您的包装器界面提供良好的测试覆盖率。这使得更改底层gem变得更加容易。
• 一旦遇到问题，请务必准备好移除/更换宝石。当您在应用程序中遇到问题需要解决时，等待外部gem维护者可能不是一个好策略。