FiveRuns Blog

As a company offering products for Ruby on Rails developers, we sometimes have to work through customer issues that are specific to certain Rails releases or Rails Edge commits. Among our daily work tasks, frictionless switching between different Rails versions is important.

Below, I’ll quickly outline our internal approach to his. It’s nothing groundbreaking, but I have noticed many developers using the tedious and time consuming gem uninstall rails;gem install rails -v old_version;gem uninstall rails;gem install rails; procedure. There is a better way.

As a starting point, you will need a copy of the Rails git repo. Since the Rails code base was moved from Subversion to git, it actually makes switching even quicker:

demo:~$ git clone git://github.com/rails/rails.git

Once I have cloned the repo locally, I can checkout a specific release tag or commit. Before I do this, let me highlight that I have the two latest Rails releases installed locally via RubyGems:

demo:~$ gem list | grep rails
rails (2.1.0, 2.0.3)

In this example, I need to quickly investigate a potential issue with an older Rails release, let’s say version 1.2.4. Inside the Rails repo, I checkout this specific tag:

demo:~$ cd rails
demo:~/rails$ git checkout v1.2.4
HEAD is now at 478cd82... Tagged 1.2.4 for release

Git does all this locally, so it also works offline. The local git repo contains the full Rails history back to its first svn commit.

Now that Rails 1.2.4 is locally checked out, I create an empty Rails app using this version. Once the skeleton has been generated, I manually freeze this version of Rails in into the vendor/rails subdirectory of the new application. This second step is necessary to avoid any conflicts with the Rails versions in my RubyGems environment:

demo:~/rails$ ruby railties/bin/rails ~/test124app
create  
create  app/controllers
create  app/helpers
create  app/models
...
demo:~/rails$ cp -r . ~/test124app/vendor/rails

Inside the skeleton app, I quickly verify that I’m using the specific Rails version I intended to use:

demo:~/rails$ cd ~/test124app
demo:~/test124app$ script/about 
About your application's environment
Ruby version                 1.8.6 (universal-darwin9.0)
RubyGems version             1.2.0
Rails version                1.2.4
Active Record version        1.15.4
Action Pack version          1.13.4
Action Web Service version   1.2.4
Action Mailer version        1.3.4
Active Support version       1.4.3
...

At the same time, the latest two Rails releases are still available in my local RubyGems installation:

demo:~/test124app$ gem list | grep -e "rails\|active" 
activerecord (2.1.0, 2.0.3)
activeresource (2.1.0, 2.0.3)
activesupport (2.1.0, 2.0.3)
rails (2.1.0, 2.0.3)

Now, I can happily test away with this Rails 1.2.4 app and at the same time work on my other Rails 2.1 apps – without any conflicts or RubyGems hassles. This concludes my little excursion about quickly switching between Rails versions. I hope it is useful to some.

If you are developing with Rails, please have a look at our free developer tool FiveRuns Tuneup. It helps you understand where your actions spent their processing time and where to improve performance bottlenecks during development.