Meaning of ~> in version requirement

Question

What's the meaning of ~> version requirement in gem specs? hanna-0.1.12 depends on [haml (~> 2.2.8)]

Answer 1

It matches any version that has the same major / minor part. This means in this case that haml ~> 2.2.8 will match any 2.2.x version.

This can be used to make sure that an API breaking change in a new gem, doesn't result in depending on that newly but changed gem that would break hanna in this case.

Answer 2

The RubyGems manual calls this a pessimistic version constraint. Its semantics are the following:

Assume you have specified an n-part version number, e.g. 1.3 (2-part) or 3.5.6.2 (4-part) as the constraint. Then, in order to fulfill the constraint, a version number must satisfy both of the following conditions:

1. The first n-1 parts of the version number must be identical to the first n-1 parts of the constraint (e.g. 1.x or 3.5.6.x match, but 0.x or 3.5.7.x don't) and
2. The last part of the version number must be greater than or equal to the last part of the constraint (e.g. 1.9999 and 3.5.6.2 match, but 3.5.6.1 or 1.2 don't).

IOW:

~> x_1.x_2.x_3. … .x_n-2.x_n-1.x_n

matches

x_1.x_2.x_3. … .x_n-2.x_n-1.y, y ≥ x_n

The reason this is called a "pessimistic" constraint, and also the use case for it, is that when you just say > x.y.z, you are being optimistic: you assume that from here on out, until all eternity, the API will never ever change. This is of course a pretty bold assumption. However, most projects have rules about when they are allowed to break backwards compatibility, and how they have to change their version number when they do break backwards compatibility. You can encode those version numbering rules using a pessimistic constraint, and thus you can be sure that your code will always continue to work (assuming that the author of the other project actually adheres to his own rules, which unfortunately isn't always the case).