Artistic rendition of Taylor Swift's '1989 (Taylor's Version)' album cover.

When I describe RBENV as a "version manager", I mean it helps developers switch between Ruby versions without too much hassle.

If we have multiple versions of Ruby installed, that means there are multiple programs on our machine which respond to the ruby command in our terminal. Without a Ruby version manager to help us switch between versions, our OS will just pick the first of these programs that it finds, which may or may not be the version our program depends on.

But why would you need multiple versions of Ruby on your machine? Why not just always use the most-recent version?

Multiple Ruby versions on one machine

Let's say your team uses the microservices approach, as opposed to the monolith approach. Over the years, you and your coworkers have created multiple Rails apps which all have a single responsibility, and which all talk to each other using API calls:

  • The oldest microservice is responsible for processing e-commerce orders, and was created back when Ruby v2.7.0 was the latest version.
  • Another microservice is the notifications service, which was created just after Ruby released v3.0.0.
  • Lastly, you have a microservice for aggregating data for the purpose of producing analytics reports on your company's sales trends. This is the most recent service, and was created using Ruby v3.3.0.

Ideally, you could simply upgrade the Ruby versions on the two older apps so that they also use Ruby v3.3.0. However, that's not always easy to do. Oftentimes, a version upgrade involves fixing your codebase to account for breaking changes that are introduced by the newer version you're upgrading to. These can take awhile to fix.

Additionally, technical priorities such as version upgrades take a back seat to product concerns such as releasing new features, bugfixes, etc. So we often have to live with older versions, at least temporarily.

What would life be like without a version manager?

Without a version manager, your options are both limited and unappealing. For example, you could...

  • ...rely on a single global Ruby version (the downsides of which are described in detail here), or
  • ...maintain separate commands for each Ruby versions (i.e. invoke ruby330, ruby275, etc. from the command line depending on which version you want to execute), which can be error-prone.

A version manager does all this work for you, without any manual effort on your part beyond declaring a version file that the manager can read from.