Many shared hosts did a quick dance up and down at the release of Rails 1.1 because a large number of their customers were floating off the gems, which meant that upgrading the gems automatically updated all the applications. Some applications couldn’t handle the upgrade (most notably Typo), so they broke. And the customers were none too happy and complained to the hosts: “Why oh why, dear host, would you upgrade and break my application?”

This is obviously bad. But nothing is so bad that you can’t learn from it. And this is a wonderful opportunity to learn that You Should Freeze Rails For Any Application In Production. Sure, we talked about that back in December, but talk is cheap (and often overheard).

So here follows a lifted finger and a promise. The lifted finger first:

If thou bless thee world with an application of open source, thou must ship it with the version of Rails that thou knowest it to work with in vendor/rails.

Here’s one counter argument that will not allow you to evade this finger: “But it’ll make my app X% larger to download”. In this day of age, nobody cares. Time is more valuable than disk space and saving hair-pulling aggravation over broken dependencies is infinitely more valuable than disk space.

Then the promise: The next version of Rails will by default extract the version of Rails it was created with into vendor/rails. This will get everyone into the Christmas spirit of being good on day one. It’ll be natural to desire less dependencies and you will soon froth at the notion of a shared host controlling the destiny of your application by choosing to update some gems. And you will be happy and content.