Rails：为gems指定版本的建议？

Question

我是rails的新手 -- 指定准确的（当前）宝石版本的利弊是什么？

下面是我引擎中的宝石。

s.add_dependency "haml-rails"
s.add_dependency "strip_attributes"
s.add_dependency "devise"
s.add_dependency "daemons"
s.add_dependency "delayed_job_active_record"
s.add_dependency "gravatar_image_tag"

1. 添加一个版本是否能保证未来版本的宝石不会破坏应用？

2. 但这不是意味着你不会得到任何bug修复吗？

Answer 1

这被认为是一个最好的实践，遵循的是 语义版本化 .总而言之，次要版本只包含bug修复，而不改变API，所以如果你想获得两全其美的效果，可以使用类似于

gem 'library', '~> 2.2'

这样你将得到最高的2.2版本(例如2.2.3)，包含了所有的错误修复，没有中断的变化。

Answer 2

您的 Gemfile.lock 将记录版本，并为你锁定它们。

使用它--与bundler。我目前必须维护一个 Rails 2.3 应用程序，而且我经常必须抵御那些认为自己已经被邀请进来的 gem 的最新版本。

Answer 3

指定宝石的版本的好处。

• 如果你指定了 gem 的版本，然后有人在 gemfile 和 bundle 安装中添加了新的 gem，那么就会有一个新的 gem。Gemfile.lock 只有在新的宝石中才会被改变。如果您的版本 不是 明确了，他们可能会意外地改变多个 gem 安装。你可能正在开发某个功能，却意外地包含了一个你没有注意到的 gem 更新。的确，您可以 应 在代码审查中抓住这个问题，但你可能不会。如果宝石版本不明确，这种事情特别多，尤其是对小白来说。
• 如果你不升级你的Rails版本，最终你可能会遇到问题，因为你的宝石版本增加，你的Rails版本不再被所有的宝石支持。

指定宝石版本的缺点。

• 如果你不指定宝石的版本，而你更新了你的 Gemfile.lock 定期，您将始终拥有最新的宝石，这可以有许多好处，包括宝石的附加功能以及提高安全性。
• 指定宝石的版本 可以 显得有点多余，因为 bundler 和你的 Gemfile.lock 文件应该承担很多管理 gem 版本的责任。从这个角度来说，开发们应该 "让工具来做这件事"，而不是自己微观管理宝石版本。
• 如果你亲自负责定期更新你的宝石，你可能就永远也绕不开了。

两全其美的办法可能是明确指定版本，然后在可能的情况下使用工具自动更新你的依赖关系，这样宝石的更新就会变成单独的提交。这样一来，如果它们引起了错误或破坏了测试，原因就更容易追查了。以下是一些类似工具的例子 gemnasium 和 dependabot. 如果你也在拉动javascript库，这将是一个很好的做法，也适用于那里。

针对你的具体问题。

1. 是的，明确版本意味着未来对那个特定的 gem 的更新不会破坏你的应用程序。
2. ...但是，是的，这也意味着你不会得到错误修复或安全改进。这就是选择一种方式而不是另一种方式的权衡。