Ruby Rot: Are your Rails apps stuck without upgrades?

I see this pattern in many projects: Someone has a good idea for a web app and creates it in Rails (2.0, at the time). The development takes some time, the project starts to include a few smaller Rails upgrades, up to perhaps 2.3.11. Rails 3 comes along, but an upgrade to Rails 3 is deemed too expensive right now, so it’s not done.

Rails 3.1 comes along, then Rails 3.2. Even an upgrade between 3.0, 3.1 and 3.2 is quite a lot of work. Upgrading your app straight from 2.3.11 to 3.2 turns into a major undertaking, so this is never planned, it never happens.

You end up with a Rails app eternally stuck at 2.3.11, sysadmins complaining left and right about your lack of Gemfile, your incompatible Ruby version (need to use 1.8.7, which doesn’t even compile properly on modern compilers…), your incompatible RubyGems versions (need to use 1.6.x since 1.8.x and higher breaks many old gems), your incompatible gems (you vendored all those gems? Oh boy.)

In the end you have something like code rot, you have Ruby Rot. No one wants to touch your app anymore. Maybe you’ll rewrite from scratch for Rails 3.2. Either way, you’ve painted yourself into a corner.

What does that teach us? Always upgrade your Rails apps as soon as a new Rails version is out? What is your strategy?

2 thoughts on “Ruby Rot: Are your Rails apps stuck without upgrades?”

  1. Yeah, it’s easy to say, but less easy to do, especially if the codebase is substantial.

    It’s even more hilarious with <2.x versions of rails :-@


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s