ruby gem 的版本控制最佳实践

Question

我经常向它添加新的宝石和功能。在我上次发布之前，我的一些代码在我的开发环境中崩溃了，我发现这是因为我的一些 gem（特别是 CarrierWave 和 jQuery）已经更新并且无法使用某些代码。

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

我知道对于某些 gem，由于错误等原因，您可能必须存储版本号。但除此之外，在开发过程中，有时我会添加新的 gem，并且可能需要执行 abundle update来让新的东西正常工作，但随后不想破坏旧东西。

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

Answer 1

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

gem carrierwave, '~>0.6.0'

这意味着 Carrierwave gem 将被冻结在 0.6 版本，但捆绑包将安装任何次要的、向后兼容的更新和错误修复，这些更新和错误修复通常是最后一个数字（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 依赖关系的工作变得更加容易，这意味着它会更快地完成。