Right, the key issue is: Can I apply a security-only patch, fairly confident that it won't introduce any regressions or break anything else in my app?
With Rails, the answer is hardly ever 'yes'. If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released -- you've got to upgrade to a new version to get a security patch, with all the treadmill time that entails. If there is a security patch release, it is often bundled with other changes that come with risk of regression (and often deliver on that risk).
I agree it's a "double edged sword"/trade-off to Rails quickly evolving nature. But the pain is very real for many of us.
I would definitely hesitate to deliver a Rails app to a customer that did not have sufficient in-house technical expertise to maintain it. I would not have nearly the same hesitation with a PHP app or an html/javascript-static-only app, even though all of them can need security patching (although the html/js only one probably only has security holes that effect the client!).
If it touches a server and a database then it has a broad attack surface, at least Rails covers a lot of the basics for SQL injection, XSS, and url manipulation.
And, you can patch a Rails app yourself in a lot of cases or go grab a gem that implements the fix for your legacy version. With Github still living on Rails 2, theres a lot of unofficial support out there.
Clearly, finding unofficial patches on github and applying is entering the realm of "this thing sure is painful to maintain", isn't it? Especially if you have multiple apps (at different legacy Rails versions) to maintain, and/or you are an enterprise that hired a contractor to deliver an app but has no in-house Rails expertise.
Yes, yes, then you might say "Well, then don't do that, keep your apps up to date, don't take on Rails apps without in-house expertise." Exactly, right. So we agree.
Yes, bugs happen, in-retrospect-wrong decisions happen. This is life. And this is part of what makes maintaining a handful of Rails apps developed under different Rails versions a pretty labor intensive thing, even with no new features.
Rails maintenance policy is summarized in the OP we are discussing. Rails 4.2.0 is now in beta. Once it is released, support policy is no more security fixes for 4.0. Rails 4.0.x was the latest Rails release until April 8 2014 when Rails 4.1.0 was released. So if you developed an app against the latest Rails minor version in March 2014, within 6 months your app is on a version that doesn't even get security updates, and needs to be upgraded. Yes, it's probably not that hard to upgrade it in this case.
And, yes, when you have a handful or more of legacy apps, and upgrades happen every ~6 months, you spend a non-trivial amount of time on the treadmill. This is my only point. I am not a Rails hater. I use Rails daily. I know of nothing better. There are all sorts of reasons that lead to maintaning Rails apps being such a time-suck, and none of them are that Rails devs are mean or moronic. But it is astonishing to me that Rails inspires a level of 'fanboy'itude that has people insisting that in fact it's not hard at all to maintain legacy Rails apps. Have you done it? With more than one app at a time? With more than 5 apps at a time?
Rails 3.2 is over two and a half years old.
