RubyGemsマニュアルではこれを 悲観的なバージョンの制約 と呼んでいます。
N部のバージョン番号を指定したとします。 1.3（2部構成）または3.5.6.2（4つの部分）を制約として使用します。次に、制約を満たすために、バージョン番号は次の両方の条件を満たす必要があります
バージョン番号の最初のn-1部分は、制約の最初のn-1部分と同じでなければなりません（例：
1.xまたは3.5.6.x一致しますが、0.xまたは3.5.7.xしないでくださいおよびバージョン番号の最後の部分は、制約の最後の部分以上でなければなりません（例：
1.9999および3.5.6.2一致しますが、1.2または3.5.6.1しないでください）。
言い換えると
〜> x1。バツ2。バツ３。 … 。バツn-2。バツn-1。バツん
マッチ
バツ1。バツ2。バツ３。 … 。バツn-2。バツn-1.y、y> = xん
これが「悲観的」制約と呼ばれる理由とその使用例は、> x.y.z、あなたは楽観的です：あなたはこれからずっと、永遠にAPIが決して変わらないと仮定します。もちろん、これはかなり大胆な仮定です。ただし、ほとんどのプロジェクトには、いつ 後方互換性の解除 を許可するか、およびdo後方互換性の解除時にバージョン番号を変更する方法に関するルールがあります。 。悲観的制約を使用してこれらのバージョン番号付けルールをエンコードできるため、コードが常に機能し続けることが保証されます（他のプロジェクトの作成者が実際に自分のルールを遵守していると仮定すると、残念ながら常にそうとは限りません） ）。
つまり、この記号を使用して、すべてのマイナーアップデートで宝石を最新の状態に保ち、アプリを破壊する可能性があるメジャーアップデートを行わないようにすることができます。
たとえば、「〜> 1.2」は、gemを1.3に更新します（そのようなバージョンがリリースされている場合）が、2.0には更新されません。
私は bundler docs これを合計すると最高だと思います：
指定子〜>には特別な意味があり、例で最もよくわかります。 〜> 2.0.3は、> = 2.0.3および<2.1と同じです。 〜> 2.1は> = 2.1および<3.0と同じです。 〜> 2.2.betaは、2.2.beta.12のようなプレリリースバージョンと一致します。