Update: Derek Prior offers much better advice on how to manage your Gemfile, so you probably want to read his article instead.
If you followed my advice in the previous post, your Gemfile would look something like this:
source :rubygems gem 'rails', '3.0.3' gem 'devise', '1.1.5' gem 'redgreen', '1.2.2' gem 'capybara', '0.4.0'
There’s nothing wrong with this except that if you wanted to keep your gems up to date frequently it would be tedious to manually change all of these versions. Fortunately, we don’t always have to be this exact with the version numbers.
Here are examples of the most useful version constraints:
gem 'foo' # use any version gem 'foo', '1.1.3' # use version 1.1.3 gem 'foo', '>=2.3.2' # use any version 2.3.2 or later gem 'foo', '>=1.2' # use any version 1.2.0 or later gem 'foo', '~>3.0.4' # use any version >= 3.0.4 and < 3.1.0 gem 'foo', '~>2.8.6' # use any version >= 2.8.6 and < 2.9.0 gem 'foo', '~>4.2' # use any version >= 4.2 and < 5.0 gem 'foo', '~>0.5' # use any version >= 0.5 and < 1.0
The ~> operator is called the pessimistic operator or the spermy operator. You can read more about it in the RubyGems docs.
Now we can type:
$ bundle update
and it will update all of our gems with the latest gem versions, respecting the version constraints we have in place.
Rational Versioning Policy
All RubyGems should follow the Rational Versioning Policy. In a nutshell, this says:
- Gem versions have three numbers. (2.4.2, 0.4.7, etc.)
- The first number should change if the gem’s interface changes in a way that breaks backwards-compatibility.
- The second number should change if the gem simply adds new capabilities to its interface.
- The third number should change when the gem only changes its inner implementation details.
This means that if you use version 2 of gem foo, any future version 2 would not break your code. Version 3 might, though. So if gem authors stick to the Rational Versioning Policy, you can safely specify versions like so:
source :rubygems gem 'rails', '3.0.3' gem 'devise', '~>1.1' gem 'redgreen', '~>1.2' gem 'capybara', '~>0.4'
without fear of your code breaking when you update the gems.
Note that Rails is too complex to follow the Rational Versioning Policy, so we should always specify an exact version of Rails.