Can I work an app using an unsupported Ruby with a newer Ruby?

Question

I have an app written using Ruby 2.2.1 and Rails 4.0.10

I did this a while ago and since then I have replaced my computer. I am trying to build my environment to work on this app and I can't seem to install Ruby 2.2.1. I keep getting the error saying I am running the system Ruby and the app uses an older Ruby. Can I use the closest Ruby to the old Ruby that is stable to work on this app or what other options do I have?

When I use rbenv to try and build the old version I get an error saying the build failed. I listed the rbenv using

 rbenv install -l

2.6.10
2.7.6
3.0.4
3.1.2
jruby-9.3.6.0
mruby-3.1.0
picoruby-3.0.0
rbx-5.0
truffleruby-22.2.0
truffleruby+graalvm-22.2.0

and it gave me this list which does not include ruby versions 2.2.1. it is not on the list.

Answer 1

rbenv, rvm, chruby and asdf are all great tools for managing multiple rubies on a single machine. They're only available on Linux and MacOS though, but if you're on Windows, there's apparently a tool called uru (which I haven't tried personally, but it's the most upvoted answer here). The last update for uru is from 2018, but it might work for older rubies, such as the one you need. Ruby and Rails can be a bit of a pain of Windows anyway, so I'd highly recommend WSL if you're on Windows and don't want to dual boot to Linux or set up a VM/Docker/something else.

If you really want to, you could just change the Ruby requirement in your Gemfile and see how it goes, but I'd recommend using a Ruby version manager and just installing the correct one to avoid any headaches from deprecated features, gem requirements, changed syntax etc.

Answer 2

TL;DR

No, you can't rely on "the closest version." That may or may not work in a given case, but is unlikely to work at all with severely outdated applications like yours.

You Can't Rely on Newer Versions to Avoid Breaking Changes

Ruby 2.2.1 is past end-of-life. So is Rails 4.0.10. While Ruby itself more or less follows semantic versioning, Rails follows a modified version where even minor versions can contain breaking changes. Other gems your Rails application relies on may or may not follow semantic versioning at all. So, you can't rely on minor and patch versions to always be backwards-compatible, especially when you're relying on third-party gems in large frameworks like Rails does.

You may also not be able to rely on native extensions to be built the same under different Ruby versions, with different compilers or dynamic library versions, or on different CPU architectures or versions of an OS. At a bare minimum, you need to use the same Ruby and the same Gemfile.lock or you're just asking for trouble.

Other Options

A Ruby version manager like RVM (which contains its own Ruby installer), or rbenv and chruby (both of which require a separate installer for building Ruby versions) will allow you to build and install multiple Rubies, including some older versions, although support for really old versions can sometimes be hit-or-miss.

Since both Ruby 2.2.1 and Rails 4.0.10 are past end-of-life, you may run into problems compiling them or finding outdated dependencies. If that happens, you can try using an official (but unsupported) Docker container for Ruby 2.2.1 with your current Gemfile.lock. If that fails, you may have to use a VM or Docker container with an older version of your OS to properly build your particular Ruby and the Rails application if either has outdated system dependencies.

Answer 3

rbenv can easily help you manage your app’s Ruby environment.

You can use different ruby version project by project. Never get locked into the system's version

vagrant and docker are also perfect solutions for manage development environment.