The Blog
To Version or Not To Version Your Gems in Gemfiles
I don’t like moving targets. I’m a software developer, not a sharpshooter. So why don’t more people version all of their gems in a Gemfile?
Here is a sample Gemfile for a Rails 3 application I was looking at yesterday.
source 'http://rubygems.org'
gem 'rails', '3.0.3'gem 'thin', '1.2.7'
gem 'will_paginate'gem 'nokogiri'gem 'haml'
The gems for Rails and thin have been versioned. Why aren’t the gems for will_paginate, nokogiri, and haml versioned? I consider un-versioned gems moving targets. Why? You’re going to get the latest version of a gem. The developer doesn’t know (or necessarily care) you depend on XXX functionality in version 1.0.23 of their gem. And so what if in version 2.0.0 of their gem, they make incompatible changes that break your application? I consider versioned gems a virtual “stake in the ground”. To the best of my abilities, with rigorous testing of course, I know that given these specific versions of gems, my application performs as expected.
What’s your opinion?
UPDATE:
Good point from my co-worker, Blake, who says that bundle will install the lastest version of a gem and then lock the version in your Gemfile.lock file on the first go-round. It could still be an issue if you do a “bundle update” locally or in your deployment process.
You can find more hilarity over on my Twitter account, CzarneckiD.
Comments
Great post David. I had a couple of question about how bundler handled some of this stuff and this gave me an excuse to look a little further into it. Turns out that when you add a dependency into the gem file, bundler will update the GemFile.lock with the dependency and the version you have installed. If you don’t have it installed it will download the latest and then specify that version in the GemFile.lock file. From that point forward bundle install will only use the version specified in the GemFile.lock even if they have a newer version on the system.
So I agree with your point that not locking down the precise version number creates a moving target, but because GemFile.lock locks it down automatically we don’t have to. We could specify the major and possibly the minor version but in reality, this probably isn’t even that big of a concern and should probably only be done once a problem with a newer version of a gem arises.