[dasil003]

It's definitely a double-edged sword, but I don't think Rails could have staid relevant without being one of the most aggressive frameworks in terms of breaking backwards compatibility.

The way I see it is that Rails is usually the wrong choice for a one-off project that a client expects you to deliver and be able to run indefinitely with no maintenance, but it's a great choice for a prototype or something that will see continual maintenance and enhancement.

My biggest frustration is just the general slowness of Ruby once you get to a non-trivial app size.

[ufmace]

I don't really see on Rails being wrong for a one-off project. It should keep running just fine as long as you don't update anything. The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something? It usually isn't too important anyways, as long as the app isn't externally accessible.

[jrochkind1]

> The only thing they'd be missing out on is security patches, but what language/framework doesn't have security patches that requires updating something?

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!).

[ch4s3]

>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.

[jrochkind1]

Sure, you can do lots of things to try to maintain your old Rails apps, but none of them are easy and reliable, especially for those who aren't Rails experts (but may be developers).

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.

[sudhirj]

Holding Rails to a minor version is quite easy (just specify it in your Gemfile) and updating patch levels shouldn't break any of your code. And security updates are still being released for Rails 3 where applicable, although 4.1 and 4.0 have already come out since then.

[jrochkind1]

Updating patch levels _has_ broken my code, several times, over the past ~18 months. Sometimes it's acknolwedged as a regression and another patch is released fixing whatever went wrong; there has been at least one time that did not happen (I could find it if you really don't believe me).

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?

[jroesch]

I second this. I recently did a port from Ruby 1.8.7 to 2.1.2 for a large Rails app (approx. ~350kloc between test and app) and in the process I was forced to update lots of dependencies. In a few places so called "minor" patches had big effects. It became clear to me that when your app gets to a significant size juggling the interactions of constantly moving versions of your Gems, Ruby, and Rails causes things to become complicated quickly.

[rhizome]

If your Rails versions is too old (which can often mean only around 12 months old), there will be no security patch released

Rails 3.2 is over two and a half years old.