3

到目前为止,我只使用 gem 名称并避免提及版本号,这是一个好习惯吗(优点:gems 会不断自动更新,缺点:应用程序可能会崩溃)

如果使用版本号是个好主意,那么使用它的标准做法是什么?

编辑 - 我刚刚做了“捆绑秀”,它显示了大约 30 多个宝石,即使我在 Gemfile 中只列出了 6 个宝石,我假设其余的是在我创建应用程序时安装的核心宝石,所以如何锁定它们还是我应该让它们保持原样?

4

5 回答 5

2

bundler 的目的之一是将您的 gem 依赖项固定到特定版本。因此,bundle在您将 gem 添加到 Gemfile 后的第一次,这些 gem 将被固定到特定版本。您必须专门bundle update <gemname>对特定的 gem 进行更新。Just bundle update(将所有 gem 更新到最新的兼容版本)在很大程度上违背了 bundler 的目的,应该避免。

也就是说,我认为只有在有特定原因的情况下才应该在 Gemfile 中提及版本。示例:您想专门运行 rails 版本 3.2.8,或者您必须使用 ruby​​-net-ldap 0.0.1,因为 0.0.2 破坏了某些功能。

于 2013-01-21T15:25:43.783 回答
2

我认为的,因为在早期,我对自行更新且不向后兼容的 gem 有很多问题。

通常,当您从一个主要版本切换到另一个主要版本时会发生这种情况,对我来说,它是 Rails 2.x 到 3.x。

所以底线是在 Gem 文件中有版本是件好事。

于 2013-01-21T11:55:01.367 回答
2

我一开始也是这么想的。

但是会有一些更新与我的编码不太匹配,或者会有不兼容的更改导致功能停止工作。

它发生在我身上至少两次,我会在 gem 被推送的那一刻更新一个 gem,而我是最早看到它全部崩溃的人之一,因为一些在推送时没有修复的 bug。所以你尝试调试它不会工作。从那时起,我会锁定有问题的 gem,只在我唯一要做的事情时升级它们,并确保功能保持不变。

建议使用您知道可以工作的版本。

之后,您可以使用gemnasium跟踪宝石

于 2013-01-21T11:56:02.250 回答
2

我的建议是YES

原因是我将外部依赖视为潜在的断点,因为它们在一定程度上不受我的控制;任何不是由我发起的外部依赖项的更改都可能导致失败。

由于软件开发已经很复杂,我强烈认为限制和控制外部依赖项更改对我们有利。

惊喜越少,维护代码就越容易。

高温高压

于 2013-01-21T13:43:49.783 回答
1

最好使用准确的版本号。您可能总是可以将其锁定到一个主要版本,或者从不指定任何版本,并且没关系,但是如果您真的想要那种细粒度的控制水平并且在您的程序在其他机器上运行时对您的程序有 100% 的信心,使用确切的版本号。

我一直处于未指定确切版本号的情况,当我或其他人执行 . 时bundle install,该项目因升级到较新版本而中断。这在部署到生产环境时尤其糟糕。

Bundler确实锁定了您的 gem 规范,但是如果您告诉它只使用主要版本,那么它会锁定它。

此外,如果没有Gemfile.lock,将代码部署到生产将是一个主要问题,因为依赖项和 gem 版本可能会发生变化。

于 2013-01-21T12:05:15.460 回答