[解決済み] バージョン要件におけるティルデグレータン（～>）の意味？

質問

の意味は何ですか？ ~> のバージョン要件は何ですか？

hanna-0.1.12 は [haml (~> 2.2.8)] に依存しています。

どのように解決するのですか？

RubyGemsのマニュアルでは、これを 悲観的バージョン制約 .

n部構成のバージョン番号を指定したと仮定すると、例えば 1.3 (2-part) または 3.5.6.2 (4-part)を制約として指定する。そして、制約を満たすためには、以下の条件を満たす必要があります。 を満たすためには、バージョン番号は次の2つの条件を満たす必要があります。

1. バージョン番号の最初のn-1個の部分は、制約条件の最初のn-1個の部分と同じでなければなりません。 の部分と同一でなければなりません。 (例えば 1.x または 3.5.6.x は一致しますが 0.x または 3.5.7.x don't) と

2. バージョン番号の最後の部分は、制約の最後の部分と同じかそれ以上でなければなりません。 制約の最後の部分 (例 1.9999 と 3.5.6.2 は一致するが 1.2 または 3.5.6.1 は使わないでください)。

言い換えると

~x

1

.x
<サブ

2

.x
<サブ

3

. ... .x
<サブ

n-2

.x
<サブ

n-1

.x
<サブ

n

マッチ

x
<サブ

1

.x
<サブ

2

.x
<サブ

3

. ... .x
<サブ

n-2

.x
<サブ

n-1

.y, y >= x

n

これがquot;pessimistic"制約と呼ばれる理由と、そのユースケースは次のとおりです。 というのは、単に > x.y.z と言う場合、あなたは楽観的です。 これから先、永遠にAPIが変更されることはないと仮定しているからです。これは はもちろん、かなり大胆な仮定です。しかし、ほとんどのプロジェクトには、以下のようなルールがあります。 を許可しています。 後方互換性を破壊する , また、次のような場合にバージョン番号を変更しなければなりません。 する 後方互換性を破壊する 互換性 このようなバージョン番号付けのルールを悲観的な そのため、自分のコードが常に動作し続けることを保証することができます。 (他のプロジェクトの作者が実際に自分のルールを守っていると仮定して) ルールに従うと仮定すると、残念ながら常にそうであるとは限りません）。