Red numbered dice

image by Terry Vlisidis

Use Loose Ruby Versioning in Your Gemfile

Patch-level versions (e.g. 2.6.3) of Ruby are compatible with each other and often only include bug fixes and security patches. Significant upgrades to the Ruby language that include new syntax or features, and make bigger changes to the language, are released once a year—as a gift for us all—on Christmas Day.

RailsConf 2024

I'm co-chairing RailsConf 2024 in Detroit May 7–9. Come and join us 

Many developers ensure their application uses a specific version in development by using a “Ruby version manager”, like rvm or, my preferred choice, chruby.

These version managers look for a file in the root directory of each app called .ruby-version. The file specifies the correct version of Ruby for this application and then automatically switches the local environment to the required version.

You can also specify your Ruby version in your Gemfile using bundler, which is more often used in your deployment environment.

Instead of…

…specifying your exact ruby version in two places and potentially generating conflicts:

# Gemfile
ruby "2.6.3"
# .ruby-version
2.6.5

This results in an error, as bundler checks the current version of Ruby.

Your Ruby version is 2.6.5, but your Gemfile specified 2.6.3

Use

…loose versioning in the Gemfile:

# Gemfile
ruby "~> 2.6.0"
# .ruby-version
2.6.5

Why?

Having a flexible Gemfile Ruby helps when deploying to environments that pre-build specific patches of Ruby and might not be as completely up to date with the latest patch versions of Ruby as soon as they are released.

Examples of services where the availability of new Ruby versions are delayed include Github Actions and Netlify.

You can generally upgrade between patch-level versions (e.g. 2.6.3 to 2.6.5) without expecting any changes to how your programme works.

The flexible constraint in the Gemfile prevents you from having to interrupt your deployment or CI process, whilst being able to upgrade your local Ruby versions.

You also only have to update your specific version in one place when you do make a change.

Additionally, with the flexible constraint, when there is a more secure patch-level version, your deployment environment will automatically upgrade your Ruby on the next deploy.

Why not?

It’s totally fine to specify the full version. This is a micro-optimisation for most use cases.

I have a preference for ‘just enough’ flexibility in the Gemfile, you may not.

Brighton Ruby 2024

Still running UK’s friendliest, Ruby event on Friday 28th June. Ice cream + Ruby 


Last updated on December 15th, 2019 by @andycroll

An email newsletter, with one Ruby/Rails technique delivered with a ‘why?’ and a ‘how?’ every two weeks. It’s deliberately brief, focussed & opinionated.