到目前为止，我只使用 gem 名称并避免提及版本号，这是一个好习惯（优点：gems 不断自动更新，缺点：应用程序可能会损坏）
如果使用版本号是个好主意，那么使用它的标准做法是什么？
编辑 - 我刚刚做了"捆绑显示"，它显示了大约 30+ 颗宝石，即使我在 Gemfile 上只列出了 6 颗宝石，我假设其余的都是在我创建应用程序时安装的核心宝石，那么如何锁定它们还是应该让它们保持不变？
我一开始也是这么想的。
但是，会有一些更新不太适合我的编码，或者会出现不兼容的更改，导致功能停止工作。
我至少遇到过两次，我会在推送宝石的确切时刻更新宝石，我是最早看到它由于推送时未修复的一些错误而全部损坏的少数人之一。所以你尝试调试，但它不起作用。从那以后，我会锁定有问题的宝石，只有在这是我唯一做的事情时才升级它们，并确保功能保持不变。
建议使用您知道有效的版本。
之后，您可以使用宝石来跟踪宝石
我的建议是肯定的。
原因是我认为外部依赖关系是潜在的突破点，因为它们在某种程度上是我无法控制的;任何不是由我发起的外部依赖关系的更改都有可能失败。
由于软件开发已经很复杂，我强烈认为限制和控制外部依赖关系的变化对我们有利。
越不意外，维护代码就越容易。
呵呵
bundler 的目的之一是将 gem 依赖项固定到特定版本。因此，在将 Gem 添加到 Gemfile 后的第一个bundle，无论如何，这些 Gem 都会固定到特定版本。您必须专门执行bundle update <gemname>才能对特定 Gem 进行更新。只是bundle update（将所有 gem 更新到最新的兼容版本）在很大程度上违背了捆绑器的目的，应该避免。
也就是说，我认为只有在有特定原因的情况下才应该提及 Gemfile 中的版本。示例：您想专门运行 rails 版本 3.2.8，或者您必须使用 ruby-net-ldap 0.0.1，因为 0.0.2 会破坏某些功能。
是的，因为在早期，我对自己更新且不向后兼容的宝石有很多问题。
通常，当您从一个主要版本切换到另一个主要版本时，就会发生这种情况，对我来说，它是Rails 2.x到3.x。
所以底线是最好在 Gem 文件中有版本。
最好使用确切的版本号。您可能总是可以将其锁定到主要版本，或者从不指定任何版本，并且没关系，但是如果您真的想要细粒度的控制级别，并且在其他计算机上运行时对您的程序有 100% 的信心，请使用确切的版本号。
我遇到过没有指定确切版本号的情况，当我或其他人进行bundle install时，该项目因进入较新版本而中断。在部署到生产环境时，这可能尤其糟糕。
Bundler确实锁定了您的 Gem 规格，但如果您告诉它只使用主要版本，那么它就会锁定它。
此外，如果没有Gemfile.lock，将代码部署到生产环境将是一个主要问题，因为依赖项和 gem 版本可能会更改。