CODEWITHSUNDEEP
ruby-on-railsruby-on-rails-3
iCyborg
iCyborg

Reputation: 4728

Should I put gem versions in my Gemfile?

Till now, I just use the gem name and avoid mentioning the version number, is this a good practice (pros: the gems keeps on getting updated automatically, cons: the app can break)

if it is a good idea to use version number, what are the standard practices to use it ?

EDIT - I just did "bundle show" and it is showing about 30+ gems even though I have only 6 gems listed at Gemfile, I am assuming the rest are core gems which get installed when I create an app, so how to lock them or should I just leave them untouched ?

Upvotes: 3

Views: 476

Answers (5)

sameera207
sameera207

Reputation: 16619

I think yes, because in the early days I had so many issue with gems which are updating by themselves, and not backwards compatible.

Normally this happens when you are switching from one major version to another, For me it's Rails 2.x to 3.x.

So the bottom line is it's good to have versions in the Gem file.

Upvotes: 2

moritz
moritz

Reputation: 25757

One of the purposes of bundler is to pin your gem dependencies to specific versions. So on the first bundle after you added a gem to Gemfile, the gems will be pinned to specific versions anyhow. You have to specifically do bundle update <gemname> to do an update on a specific gem. Just bundle update (which updates all gems to the most recent compatible versions) defeats the purpose of bundler to a large extent and should be avoided.

that said, I think one should only mention versions in Gemfile if one has a specific reason for it. Example: You want to run rails version 3.2.8 specifically or you have to use ruby-net-ldap 0.0.1 because 0.0.2 breaks some functionality.

Upvotes: 2

Nazar
Nazar

Reputation: 1509

My suggestion would be YES.

Reason being is that I view external dependencies as potential breaking points as they are out of my control to a certain extent; any change that an external dependency that isn't initiated by me is a potential for a failure.

Since software development is already complicated, I strongly feel that both limiting and controlling external dependency changes works to our advantage.

The less surprise there is the easier it is to maintain code.

HTH

Upvotes: 2

sjain
sjain

Reputation: 23344

It's good to use the exact version numbers. You can probably always just lock it down to a major version, or never specify any version, and be okay, but if you really want that fine grained level of control and to have 100% confidence in your program when being run on other machines, use the exact version numbers.

I've been in situations where the exact version number wasn't specified, and when I or someone else did a bundle install, the project broke because it went to a newer version. This can be especially bad when deploying to production.

Bundler does lock in your gem specifications, but if you're telling it to just use a major release, then it locks that in.

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

Upvotes: 1

Nick Ginanto
Nick Ginanto

Reputation: 32120

I thought so too at the beginning.

But then there would be some updates which didn't quite fit to what I coded, or there would be incompatiblie changes which cause feature to stop working.

it happened to me at least twice that I would update a gem at the exact moment the gem was push and I was one of the first few to see it all break due to some bug that wasn't fixed at the time of the push. So you try to debug and it won't work. Since then, I would lock problematic gems and only upgrade them when that's the only thing I'm doing and make sure the functionality remained the same.

It is advisable to use versions which you know that work.

After that you can use gemnasium to keep track on the gems

Upvotes: 2

Related Questions