新しい宝石と機能を頻繁に追加しています。前回のリリースの前に、コードの一部が開発環境で壊れていました。その原因は、いくつかの gem (特に CarrierWave と jQuery) が更新され、一部のコードで動作しなかったことが原因であることがわかりました。
バージョニングに関してgemを管理する最良の方法は何ですか? Gemfile では常にバージョン番号を指定する必要があると言う人もいますが、すべての gem については? ほんの一部？
いくつかの gemでは、バグなどのためにバージョン番号を保存しなけれbundle updateばならない場合があることを知っています。古いものを壊したくない。
うまくいけば、本番環境にプッシュする前に多くのエラーをキャッチするための優れたテストがあります。他のユーザーは、gem の更新が開発中にまったく関係のない機能を壊さないようにどのように保証していますか?
残念ながら、下位互換性のない 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 には更新されません。
いくつかの考慮事項:
すべての gem バージョンを指定する必要はありませんが、指定することをお勧めします。たとえば、自分の宝石のバージョンは指定しません。ただし、すべてのサードパーティの gem には、そのバージョンが指定されています。そうでなければ、私は自分のコードを自分の制御を超えたものに信頼していたでしょう.
悲観的な演算子を使用するには、gem のメンテナーをある程度信頼する必要があります。無謀なメンテナーは、下位互換性のない変更をマイナー バージョンでリリースする可能性があります。そのような場合、マイナー バージョンをロックします (悲観的な演算子はありません)。
gem のバージョンを指定すると、gem の依存関係を解決するバンドルの作業がはるかに簡単になります。つまり、はるかに高速になります。