Ruby-on-rails – Should I specify exact versions in the Gemfile

bundlerrubyruby-on-railsruby-on-rails-3rubygems

I've noticed that on rubygems.org a lot of the gems suggest you specify them by major version rather than exact version. For example…

The haml-rails gem

gem "haml-rails", "~> 0.3.4"  # "$ bundle install" will acquire the 
                              # latest version before 1.0.

However, based on the Bundler docs it sounded to me like it would be better to nail down the exact version like this…

gem "haml-rails", "0.3.4"

So there's your haml-rails gem and all its dependencies won't drift forward. If you check out the project on a different machine a few weeks later and run $ bundle install you'll have precisely the same versions of everything you specified.

I've seen point releases break stuff, and I thought part of the whole idea of Bundler was to "Bundle.lock" all your gem versions.

But on rubygems.org they use "~>" a lot so maybe I'm missing something?

Any clarification would be very helpful to me in understanding Bundler and gem management.

Best Answer

This is the purpose of the Gemfile.lock file - running bundle install with a Gemfile.lock present only installs using the dependencies listed in there; it doesn't re-resolve the Gemfile. To update dependencies / update gem versions, you then have to explicitly do a bundle update, which will update your Gemfile.lock file.

If there wasn't a Gemfile.lock, deploying code to production would be a major issue because, as you mention, the dependencies and gem versions could change.

In short, you should be generally safe using the pessimistic version constraint operator (~>) as rubygems.org advises. Just be sure to re-run your tests after you do a bundle update to make sure nothing breaks.

There's a nice article by Yehuda Katz that has a little more info on Gemfile.lock.