CODEWITHSUNDEEP
ruby-on-railsrubyruby-on-rails-3ruby-on-rails-4rubygems
Hopstream
Hopstream

Reputation: 6451

Rails: pros/cons of specifying versions for the gems?

I'm new to rails -- what are the pros and cons are of specifying the exact (current) gem versions?

Here are the gems I have in my engine:

s.add_dependency "haml-rails"
s.add_dependency "strip_attributes"
s.add_dependency "devise"
s.add_dependency "daemons"
s.add_dependency "delayed_job_active_record"
s.add_dependency "gravatar_image_tag"

  1. Does adding a version ensure a future version of the gem doesn't break the app?

  2. But wouldn't that mean your won't get any bug fixes?

Upvotes: 1

Views: 120

Answers (3)

David Kennell
David Kennell

Reputation: 1227

Pros to specifying the versions of your gems:

  • If you specify your gem versions, and then someone adds a new gem to the gemfile and bundle installs, the Gemfile.lock only gets altered for the new gem. If your versions aren't made explicit, they might accidentally alter multiple gem installs. You might be working on some feature, and accidentally include a gem update that you didn't notice. It's true that you should catch this in code review, but you might not. This sort of thing especially often, especially to juniors, if gem versions aren't explicit.
  • If you don't upgrade your Rails version, eventually you may run into problems as your gem versions increase, and your Rails version is no longer supported by all of your gems.

Cons to specifying the versions of your gems:

  • If you don't specify the versions of your gems, and you update your Gemfile.lock regularly, you will always have up-to-date gems, which can have many benefits including added functionality from the gems as well as improved security.
  • Specifying the versions of your gems could be seen as a bit redundant, since bundler and your Gemfile.lock file are supposed to have a lot of the responsibility of managing gem versions. From this point of view, devs should "let the tool do the work" instead of micromanaging gem versions themselves.
  • If you're personally responsible for regularly updating your gems, you might just never get around it.

The best of both worlds may be to specify the versions explicitly, and then use a tool for automatically updating your dependencies when possible, so that the gem updates end up being separate commits. This way, if they cause bugs or break tests, the cause is easier to track down. Some examples of tools like this are gemnasium and dependabot. If you are also pulling in javascript libraries, this would be a good practice to apply there as well.

In response to your specific questions:

  1. Yes, making the version explicit means that a future update to that particular gem won't break your app.
  2. ...but yes, this also means that you don't get bug fixes or security improvements. This is the tradeoff in choosing one way over the other.

Upvotes: 0

Phlip
Phlip

Reputation: 5343

Your Gemfile.lock will record the versions, and lock them for you.

Use it - with bundler. I currently must maintain a Rails 2.3 app, and I frequently must fend off the latest versions of gems that think they have been invited in.

Upvotes: 0

TheRusskiy
TheRusskiy

Reputation: 1101

It is considered to be a best practice to follow semantic versioning . To sum it up minor versions only contain bug fixes and don't change the API, so if you want to get best of both worlds use something like

gem 'library', '~> 2.2'

this way you will get highest 2.2 version (e.g. 2.2.3) with all the bug fixes and no breaking changes.

Upvotes: 2

Related Questions