Руководство 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
не соответствуют).
Другими словами
~> x<sub>1</sub>.x<sub>2</sub>.x<sub>3</sub>. … .x<sub>n-2</sub>.x<sub>n-1</sub>.x<sub>n</sub>
соответствует
x<sub>1</sub>.x<sub>2</sub>.x<sub>3</sub>. … .x<sub>n-2</sub>.x<sub>n-1</sub>.y, y >= x<sub>n</sub>
Причина, по которой это называется "пессимистическим" ограничением, а также сценарий его использования, заключается в том, что когда вы просто говорите > x.y.z
, вы настроены оптимистично: вы предполагаете, что с этого момента и до бесконечности API никогда не изменится.Это, конечно, довольно смелое предположение.Однако в большинстве проектов есть правила о том, когда им разрешено нарушать обратную совместимость , и как им нужно менять номер версии, когда они делают нарушать обратную совместимость.Вы можете кодировать эти правила нумерации версий, используя пессимистические ограничения, и, таким образом, вы можете быть уверены, что ваш код всегда будет работать (при условии, что автор другого проекта действительно придерживается своих собственных правил, что, к сожалению, не всегда так).).