ruby gem 的版本控制最佳实践

Question

我经常向它添加新的宝石和功能。在我上次发布之前，我的一些代码在我的开发环境中出现了问题，我发现这是因为我的一些 gem（尤其是 CarrierWave 和 jQuery）已经更新并且不能与某些代码一起使用。

在版本控制方面管理 gem 的最佳方式是什么？有些人似乎说您应该始终在 Gemfile 中指定版本号......但是对于所有 gem？只是一些？

我知道，对于某些 gem，您可能 因错误等原因存储版本号。但除此之外，在开发过程中，有时我会添加新的 gem，并且可能需要做一个bundle update 让新的东西工作，但又不想破坏旧的东西。

我有很好的测试，希望能在投入生产之前发现很多错误。在开发过程中，其他用户如何确保 gem 更新不会破坏完全不相关的功能？

Answer 1

不幸的是，如果您不希望您的应用程序因为向后不兼容的 gem 更新而中断，您必须指定 gem 版本。我发现一个好的做法是使用悲观运算符~> 来指定gem 版本。例如：

gem carrierwave, '~>0.6.0'

这意味着 carrierwave gem 将在 0.6 版本中被冻结，但 bundle 将安装任何小的、向后兼容的更新和错误修复，这些更新和错误修复通常是最后一个数字的增量（0.6.1、0.6.2...） .这意味着您可以更新您的捆绑包，而不会冒破坏某些东西的风险（运行bundle update 时不再畏缩）。

您也可以在主要版本上使用悲观运算符：

gem devise, '~>2.0'

意味着捆绑包将更新到版本 2.1.0、2.2.0、2.2.1、2.3.0，但永远不会更新到 3.x。

一些注意事项：

1. 您没有必须指定所有 gem 版本，但这是一个很好的做法。例如，我没有指定我自己的 gem 的版本。但是每个第三方 gem 都有指定的版本。否则，我会把我的代码信任到我无法控制的事情上。

2. 您仍然需要对 gem 维护者有一定的信任才能使用悲观运算符。鲁莽的维护者仍然可以在次要版本中发布向后不兼容的更改。在这些情况下，我锁定了次要版本（没有悲观操作符）。

3. 如果您指定 gem 版本，您将使 bundle 解决 gem 依赖项的工作更容易，这意味着它会更快。