Rails：为宝石指定版本的优点/缺点？

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. 添加版本是否确保未来版本的gem不会破坏应用程序？

2. 但这不意味着您不会修复任何错误吗？

Answer 1

遵循semantic versioning被认为是最佳做法。 总结一下，次要版本只包含错误修复，不要更改API，所以如果你想要充分利用这两个世界，请使用

gem 'library', '~> 2.2'

通过这种方式，您将获得最高2.2版本（例如2.2.3），其中包含所有错误修复和无重大更改。

Answer 2

您的Gemfile.lock会记录版本，并为您锁定。

使用它 - 与bundler一起使用。我目前必须维护一个Rails 2.3应用程序，而且我经常必须避免认为他们被邀请进入的宝石的最新版本。

Answer 3

指定宝石版本的优点：

• 如果您指定gem版本，然后有人将新gem添加到gemfile并捆绑安装，则Gemfile.lock仅会更改为新gem。如果您的版本未明确显示，则它们可能会意外更改多个gem安装。您可能正在使用某些功能，并且偶然包含了您没有注意到的gem更新。的确，您应该在代码审查中抓住了这一点，但您可能没有。如果未明确显示gem版本，这种情况尤其常见，尤其对于初级用户。
• 如果您不升级Rails版本，最终您可能会遇到问题，因为您的gem版本增加，并且所有的gem不再支持您的Rails版本。

可以指定宝石的版本：

• 如果您未指定宝石的版本，并定期更新Gemfile.lock，则您将始终拥有最新的宝石，这可能会带来很多好处，包括从宝石中增加功能作为提高的安全性。
• 指定宝石的版本 可能有点多余，因为捆绑程序和Gemfile.lock文件应该承担管理宝石版本的大量责任。从这个角度来看，开发人员应该“让工具完成工作”，而不是自己亲自管理gem版本。
• 如果您个人负责定期更新自己的宝石，则可能永远无法解决它。

两全其美的做法可能是明确指定版本，然后在可能的情况下使用一种工具来自动更新依赖项，以便gem更新最终成为单独的提交。这样，如果它们导致错误或破坏测试，则更容易找出原因。像gemnasium和dependabot这样的工具。如果您还引入了javascript库，那么在此应用JavaScript库也是一个好习惯。

针对您的特定问题：

1. 是的，明确显示版本意味着将来对该特定gem的更新不会破坏您的应用。
2. ...但是是的，这也意味着您没有得到错误修复或安全性改进。这是选择一种方式而不是另一种方式的权衡。