Tip for users of Rails 1.1.6 and earlier

If you have a Ruby on Rails application that originally used Rails 1.1.6 or earlier, you might have trouble after yesterday’s Rails update (which also updated several other Ruby “gems”, including the “RubyGems” gem itself).

In old versions of Rails, the “config/boot.rb” file that starts the Rails application contained this line:

require_gem "rails", "=#{version}"


However, the “require_gem” command was removed in RubyGems 1.0.0.

Later versions of Rails use a different command in boot.rb that works properly with subsequent versions of RubyGems. But for Rails 1.1.6 and earlier, RubyGems updates can break the application unless you’ve updated your boot.rb file at some point. And because boot.rb is executed even before Rails starts, the problem can happen even if you’ve frozen Rails.

There are many ways to update boot.rb, but changing “require_gem” to “gem” is the simplest in most cases:

gem "rails", "=#{version}"


We’re surprised that the RubyGems developers would make such a far-reaching change that can completely break older Rails applications. What’s worse is that the developers don’t seem to realize how important stability and backwards compatibility is: when people complained about this, one of the developers said,

Kernel#require_gem has been complaining about deprecation for 11 months. There’s been plenty of time for authors to fix their code.

That’s absurd. People who deploy production applications expect them to work for far longer than 11 months. This kind of change should be left as deprecated-but-working for at least several years before being removed.

The supposed advantage of Rails is “Convention over Configuration”, meaning that once you know how to use it, you don’t need to worry about how to configure it to handle the basic “conventional” parts of an application. But in our experience, keeping Rails apps working is far harder than it is in other languages, precisely because the necessary “invisible” configuration (and the Rails “language” syntax itself) often undergoes changes.

Freezing Rails avoids many of these problems, and that’s a useful feature that the Rails developers should be applauded for. On the other hand, Rails would be essentially unusable without that feature, so perhaps not so much.

Here’s an open plea to developers of all languages, toolkits, modules, and so on: like all hosting companies, we have customers that don’t touch their deployed apps (or look at the log files they generate) for literally years, as long as they seem to keep working. When you deprecate something, please try to keep it actually working for as long as possible afterward, unless there’s a really, really good reason (like security) to do otherwise. Backward compatibility is a sign of a robust, mature platform, which attracts more users. It’s in your interest, even if it’s more work.