CODEWITHSUNDEEP
ruby-on-railsrubygemsbundler
bo-oz
bo-oz

Reputation: 2872

Should I set explicit versions in a Gemfile?

I'm used to defining gemfiles with simple commands, like gem 'devise'. I'm now putting my App in production through a dockerized container on AWS, together with a pipeline that pulls and builds new containers based on pushes to my master branch on Git. This means that every time I push a new version, AWS will rebuild the entire app from scratch, also installing all the latest versions of the gems.

I'm having some concerns what will happen when there are new versions of gems. This could of course mean that my code could stop working, if the included gems change their behaviour or methods.

What is the best practice is this case? Should I start explicitly defining what versions of the Gems I want? And if so, how do I make sure that I do profit from the fixes that are provided?

I'm considering defining all my gems like this:

gem 'devise', '~> 4.6.0'
# Or
gem 'devise', '~> 4.6'

What would be the most flexible, but "ensuring" I don't run into any issues in the long run?

Upvotes: 2

Views: 628

Answers (1)

Vasfed
Vasfed

Reputation: 18454

Unexpected version changes should usually be prevented by Gemfile.lock, that contains exact versions that were last installed/upgraded and is committed alongside gemfile and can be used to ensure production can be built each time exactly the same. First I'd look into why your build pipeline does not use it.

Even if you have CI and good tests coverage that will prevent production from breaking, it's much better to be sure that something broke not because of your changes, but a gem update. Thus gem updates, even to minor and patch versions, should come in separate commits.

As for versions in gemfile itself - you should specify version dependencies according to version policy of that specific gem (even when relying on a lock-file). Most gems use semantic versioning, so that gem should not break anything within one major version (~>4.6 option) and updates should not require major changes to your app (but anyway there may be deprecations that flood your log or some regressions, so in any case it's better to have a version tested before production).

To stay updated about new versions of dependencies - periodically run bundle outdated to see which gems updates are there.

Upvotes: 3

Related Questions