4 ms·

The conversation in this comments has become a lightning rod for Rails hate, and the "impossibility" of upgrading! (Somewhat to be expected on HN.) However, fo

The conversation in this comments has become a lightning rod for Rails hate, and the "impossibility" of upgrading! (Somewhat to be expected on HN.) However, for almost all Rails developers, upgrading is usually not a huge issue, at least since Rails 3 came around. I've been doing Rails development for 3 years, and I've yet to spend more than a couple hours on an upgrade. All in all, you have to realize this -- Rails upgrading troubles are something that happen once a year, maybe twice a year at best. In the worst case it'll take about half a day of work. Is it really worth tossing the whole framework out just because of that? Here's my take on the 4 possible issues the author mentioned: 1) If you're >= Rails 3, almost all upgrades are painless. Even Rails 3 -> Rails 4 wasn't that bad, as the only sort of breaking change was strong parameters. The difficulty of changing that varies greatly on the size of your application, but it's more likely just a tedious couple hours of work and you're done. 2) Application size - see above. 3) Use of external libraries - eh, what I usually do is just wait a few weeks when the next edge Rails comes out, and by that point, the open source community has fixed its stuff. Or, even better, contribute! 4) Test coverage - I've never been at a legitimate Rails shop that doesn't do test coverage. Testing is brought to the extreme with all Rails apps -- and if you aren't writing tests, you probably aren't a Rails dev.

bronbron 13y ago
What usually happens is people decide to upgrade everything all at once, since they're investing the time anyway. So they upgrade to Ruby 2, Rails 4, JQuery 2, etc. all at once. Since the big driver was to upgrade Rails initially, Rails becomes the focal point of all the once-deprecated-now-removed errors that occur. That being said, upgrading from Rails 2 -> 3 was pretty annoying.
stiff 13y ago
Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently at around 50k lines of code. When you are taking about "couple hours of work" and "painless" I can only laugh out loud. Every new minor or major Rails version migration takes several weeks with any larger app, only patch versions can be migrated reasonably smoothly. Migration from Rails 2.3 to Rails 3.0 was a particular catastrophe, it took me more than a month of intensive work, after the switch the application became twice as slow, which turned out to be a regression in the PostgreSQL driver that went unnoticed for a year since Rails 3.0 was first released. Just diagnosing this single issue took me a week of frustration, where I step by step peeled the onion of abstraction upon abstraction, having to profile Rails internals in the end. We are now looking into the Rails 3 -> Rails 4 migration, and it's not much better, after just changing the gems the application won't start, the console won't start, and the tests run into an infinite recursion and explode the stack. I routinely spend a week even to get just those three basic things to start at all, and it was this way even when migrating 1.x to 2.x. After every upgrade of this kind, some gems turn out to be abandoned are not upgraded by the authors to support the newer Rails, and seldom they will work with them without changes. The ones that were updated, often require a separate upgrade procedure of their own, there goes another week. Just fixing all the deprecation warnings will take another one. It's not just strong parameters, a lot of the old routing code does not work, conditions on relations don't work anymore, config settings become obsolete and so on and so forth, 80% of the things that have to be changed are not even in the release notes, for example Rails 4.0 happened to introduce an internal Options class that is visible from every controller and shadows our global Options constant which is the object with application configuration. It does not mean Rails "sucks" or anything like this, but keeping a very nice API while adapting a framework to requirements evolving over the years has the cost of sucking at compatibility, that's just a fact of software engineering. So please lets not pretend the Rails team top priority is ease of long term maintenance and lets put things as they are. If you are not systematically keeping up with newer Rails version, after half a year or 9 months since the last update you won't even receive bugfixes, because they often aren't backported even to the previous minor version. That the 37signals guys threw out their own biggest app and rewritten it from scratch is also telling about their attitude to things of this kind. So Rails is bad at compatibility, in exchange it keeps delivering a really nice API for a wider and wider scope of tasks.
- dylandrop 13y ago
  NB, I said: "If you're >= Rails 3, almost all upgrades are painless. " I was talking about upgrades past Rails 2 -> 3. That was probably the biggest one in Rails history, but even that was a problem you should have only encountered almost 3 years ago by now. 3 -> 4 is not nearly as crazy. Recently one of the more senior devs at a place I worked at coverted a 50k line codebase from 3 -> 4 in one day. Not bad.
- zpe 13y ago
  We've upgraded a similarly large project and for us the two following mistakes caused the majority of headache: 1) Adapting libraries without regards to long term maintenance. I.e. single person project that he/she does because a current client needs it, without planning on having to take over stewardship of the library or fork it when the person eventually abandons it. 2) Adapting libraries that hook into rails internal apis, without writing this shortcut up as a debt that you might have to pay later when the private api changes.
yxhuvud 13y ago
Painless? ruby 1.8.7/rails 3.0 -> ruby 1.9/rails3.2 took a LOT of time and more than 100 commits. Not to mention the time spent repacking an infinite amount of dependencies, but that is more of an issue of our packaging model (we put everything in rpms) than of rails.

bronbron 13y ago

What usually happens is people decide to upgrade everything all at once, since they're investing the time anyway. So they upgrade to Ruby 2, Rails 4, JQuery 2, etc. all at once. Since the big driver was to upgrade Rails initially, Rails becomes the focal point of all the once-deprecated-now-removed errors that occur. That being said, upgrading from Rails 2 -> 3 was pretty annoying.

stiff 13y ago

Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently at around 50k lines of code. When you are taking about "couple hours of work" and "painless" I can only laugh out loud. Every new minor or major Rails version migration takes several weeks with any larger app, only patch versions can be migrated reasonably smoothly. Migration from Rails 2.3 to Rails 3.0 was a particular catastrophe, it took me more than a month of intensive work, after the switch the application became twice as slow, which turned out to be a regression in the PostgreSQL driver that went unnoticed for a year since Rails 3.0 was first released. Just diagnosing this single issue took me a week of frustration, where I step by step peeled the onion of abstraction upon abstraction, having to profile Rails internals in the end. We are now looking into the Rails 3 -> Rails 4 migration, and it's not much better, after just changing the gems the application won't start, the console won't start, and the tests run into an infinite recursion and explode the stack. I routinely spend a week even to get just those three basic things to start at all, and it was this way even when migrating 1.x to 2.x. After every upgrade of this kind, some gems turn out to be abandoned are not upgraded by the authors to support the newer Rails, and seldom they will work with them without changes. The ones that were updated, often require a separate upgrade procedure of their own, there goes another week. Just fixing all the deprecation warnings will take another one. It's not just strong parameters, a lot of the old routing code does not work, conditions on relations don't work anymore, config settings become obsolete and so on and so forth, 80% of the things that have to be changed are not even in the release notes, for example Rails 4.0 happened to introduce an internal Options class that is visible from every controller and shadows our global Options constant which is the object with application configuration. It does not mean Rails "sucks" or anything like this, but keeping a very nice API while adapting a framework to requirements evolving over the years has the cost of sucking at compatibility, that's just a fact of software engineering. So please lets not pretend the Rails team top priority is ease of long term maintenance and lets put things as they are. If you are not systematically keeping up with newer Rails version, after half a year or 9 months since the last update you won't even receive bugfixes, because they often aren't backported even to the previous minor version. That the 37signals guys threw out their own biggest app and rewritten it from scratch is also telling about their attitude to things of this kind. So Rails is bad at compatibility, in exchange it keeps delivering a really nice API for a wider and wider scope of tasks.

dylandrop 13y ago
NB, I said: "If you're >= Rails 3, almost all upgrades are painless. " I was talking about upgrades past Rails 2 -> 3. That was probably the biggest one in Rails history, but even that was a problem you should have only encountered almost 3 years ago by now. 3 -> 4 is not nearly as crazy. Recently one of the more senior devs at a place I worked at coverted a 50k line codebase from 3 -> 4 in one day. Not bad.
zpe 13y ago
We've upgraded a similarly large project and for us the two following mistakes caused the majority of headache: 1) Adapting libraries without regards to long term maintenance. I.e. single person project that he/she does because a current client needs it, without planning on having to take over stewardship of the library or fork it when the person eventually abandons it. 2) Adapting libraries that hook into rails internal apis, without writing this shortcut up as a debt that you might have to pay later when the private api changes.

yxhuvud 13y ago

Painless? ruby 1.8.7/rails 3.0 -> ruby 1.9/rails3.2 took a LOT of time and more than 100 commits. Not to mention the time spent repacking an infinite amount of dependencies, but that is more of an issue of our packaging model (we put everything in rpms) than of rails.