Here's my take on Matt's post titled Learning from Rails’ failures. I'd like to touch on some of the points he's raised and then continue on with some of my thoughts.
Upgrading
I'm not sure if I'm doing something wrong but for the past 4-6 months, upgrading my apps haven't been as painful as Matt seems to suggest. Of course, the largest version-gap I've attempted has been a 3.0.x to 3.2.1 and I'd take the upgrades step-by-step considering 3.1 brought about a lot of changes.
The first thing I do is to do an app diff against a newly generated app 'template' to see where the generators have added/removed configs etc. I'd then proceed to tackle the update from a dependencies perspective and this is inherently tricky for the simple reason that the older the app you are upgrading, there's a good chance quite a bit has changed in your dependencies (gems). Heck, Devise 2.0 is already old news...
What’s worse is that plugins/gems might or might not compatible with the version you are updating to, but you will only know that by trying yourself and letting others try and report potential issues.
I don't think there is a semantic means for avoiding the above, apart from upgrading often and trying to hug as close to new releases — but is this really viable?
If you’re using the WordPress blog engine, you know how easy and safe it is to upgrade the engine or the plugins. Granted WordPress isn’t a web dev framework, but it gives you an idea of what kind of experience we should be striving for.
Matt has clearly pointed out that these aren't tomatoes vs. tomato — what he's trying to point out is the simple 'worry' free upgrade that WordPress tends to offer.
It might be asking for much to expect Rails to reach that point of 'plug-n-play' considering the whole point of Rails is bespoke integration — we are tying in MVC, REST/CRUD, plus a plethora of gems, mixins, engines, and the list goes on with background jobs (Resque/Redis as an example).
When upgrading across major versions of Rails apps one tends to find big changes - case in point would be the routing DSL change between 2.X and 3.X as well as the AR query DSL in particular; it's fair to expect a less than straightforward upgrade path there.
To drive my point home, I just rebased my development branch onto master and upgraded this blog from Rails 3.1.2 to 3.2.1.
Before this post even gets published, my blog has been upgraded! Here's me updating my production server and restarting the Passenger instance
Of course, I did due diligence by checking that all was OK by firing my dev (thin) server up first.
Stability vs. Bleeding Edge Phun...
But from my perspective, that shouldn’t come to the cost of stability. Rails 3′s new asset pipeline is a good example of a half-baked solution shoved in a release at the last minute and creating a nightmare for a lot of us trying to upgrade. I know, I know, you can turn off the asset pipeline and it got better since it was first released. But shouldn’t that be the other way around?
Hmm - that's indeed a tough one. At first I too found myself pulling my hair out over the pipeline and it was at least a month or so after launch till Ryan Bigg made one of his 'epic' blog posts detailing the guts of the asset pipeline — even later so till he updated the Rails Guides with details on its usage.
During those few months, I did the most sensible thing and that was to simply continue to serve assets from public/ until I had enough time to play around with the asset pipeline and get used to finding what would cause Sprockets to essentially die. One such case was dumping the entire source for CKEditor into app/assets/javascripts/ — a hugely bloated application.js and it (at the time) made Heroku's Cedar stack very unhappy when attempting to precompile the JS.
So, Yes, I agree with Matt that such changes to Rails need to be handled better. Adoption shouldn't be forced but rather up to us — then again I do wonder if we'd bothered so much about it if it was optional. Thoughts?
I'm quite happy leaving it 'on' as I do like the minified JS/CSS and the smarter asset caching that it provides out of the box. The only gotcha is that I always forget running rake assets:precompile when deploying new apps. That'll teach me to be less-lazy and deploy with Capistrano.