Rails: How to smell an immature framework

This last week, I've been battling to get a Rails 1.x application moved to a hosting provider that has graciously upgraded to Rails 2.x. There is no migration documentation to be found aside from a scarce upgrade notes file.

Now this is where the clincher is: Rails is a Ruby FRAMEWORK and yet, the hosting provider gets to pick which version I'm running. Obviously, this leads to a forced migration in a production environment. If they decided to upgrade the Ruby language processor it would be a different story. It seems like the Rails team didn't take a hint from the abomination that was PEAR / PECL due to hosting providers bearing the responsibility of versioning what were essentially early extensions of the PHP language.

Why can't I run my own Rails instance? Well hosting providers are being sold on mod_ruby which is really mod_rails. That's like your hosting provider installing mod_zend_framework and then getting to pick the version as it comes out. Let's not forget that four years ago, Zend didn't exist and Rails was a pet project by an young, but innovative group soon to be known to the world as 37Signals.

What bothers me is that this application is a little over a year old and due to the naming changes in the Rails tree (without graceful failures for deprecated functionality) I'm stuck hunting down why each controller is failing. Thankfully, if you're clever in ASP.NET, you can include a lib/ folder with any binaries required for compilation, and the codebase has matured to the point that migrations only occur at the *.5 release. You have to give Microsoft credit for not breaking backwards compatibility as well. As much as they get burned in the browser wars for this reason, it does mean that you're not forced to unravel the cobwebs on a deployed application and spend a week debugging it after 13 months!

While PHP 5.3 is offering some radical enhancements (like namespaces!) to the PHP language, they're at least waiting until 6.x before dropping some of the painful design decisions (like magic quotes etc...) that were made what is forever (more than 2 years!) by web development standards.

Ultimately, having an Apache module design to work with a specific version of a framework sounds like a mix of concerns. Why does the webserver module need to know the details of how Rails handles it's templating engine, or how it dispatches requests? Why is it so bloody complicated to get standardized rails hosting? Why do people develop in webrick, deploy using FastCGI and then have to deal with mod_ruby.

My suggestion is either buy your own machine, get virtual hosting environment, or wait until the dust settles and a unified development / testing / production environment presents itself.