

Upgrading a Rails 2.1 app to 3.2 (slidedeck) - derwiki
http://derwiki.tumblr.com/post/28038287010/upgrading-a-rails-2-1-app-to-3-2

======
lloeki
We are precisely in that process, where one of our apps (Ruby 1.8.7+Rails 2.1,
originally Ruby<1.8+Rails 1.x) has been forked at some point. Due to various
mishaps, the main, generic branch got so rotten that we're simply dropping it
and built a brand new version, but the customer-specific, simpler fork is
deemed "recoverable" (although there's a good pile of code worthy of TDWTF
it's miles better than in the main branch). We're currently cleaning up all
the WTFs, "delet[ing] as much code upfront as [we] can", and the next step is
dropping 1.8.7 in favor of 1.9.3, and subsequently bump to Rails 3. That's
still a long winded road ahead.

~~~
wincent
FWIW, we did this in the opposite order (first Rails 3/3.2, then Ruby 1.9).
The bigger wins in developer productivity and access to shiny new toys are to
be had by jumping to the latest Rails version. Updating Ruby is just the icing
on the cake.

~~~
damncabbage
Definitely agreed. I'm working on a 1.8.7 site for the last six months, and
it's been perfectly workable. Some gems do make the assumption of 1.9, though,
which can suck.

(We just upgraded to 1.9.3)

~~~
Argorak
I recently dropped all official 1.8.7-support for all my projects. Informally,
most of them should still work (tm). 1.8.7 is past its EOL and will only
receive security fixes until next year. Not having a migration planned for the
near future is reckless.

~~~
damncabbage
_Not having a migration planned for the near future is reckless._

I'd argue that doing both a Rails 2 -> 3 upgrade at the same time as a Ruby
1.8.7 -> 1.9 upgrade is more reckless. I do agree that it would need to happen
damn soon, though, but not concurrently.

------
alexyoung
I've migrated a few large apps to 1.9/3.x, and it's the least fun I've ever
had as a developer. The API changes in Rails and the burden they place on
developers makes me think twice before using Rails for new projects.

After a while I ended up with a set of Vim macros that handle a lot of the
superficial changes, but it's still painful drudgery that makes me wish I was
working with a language and framework that's less fickle.

And, be wary of projects with a lot of dependencies and plugins. Think very
carefully before adding a single gem to a project.

~~~
pilif
> The API changes in Rails and the burden they place on developers makes me
> think twice before using Rails for new projects

you can always switch to PHP - they keep their API stable for years.

Of course everybody equally hates them for that because keeping a stable API
also means keeping warts.

So what is the correct way to go? Only fix the API's I'm not using? That would
be great for myself, but what about everybody else?

I very much agree with your comment about dependencies though. When you decide
to take on a dependency, never decide based on what work it saves you right
now - also think about how much work it will be to fix it for the future.

On the other hand, NIH is bad either. It's really hard to find the correct
middle-ground.

------
cygwin98
We had the same experience with one of our main Rails apps recently. The
original version was written in 2007 in Rails 1.2.x and Ruby 1.8.6. Since
then, lots of features have been added, which of course inflated LOC and
increased gems/plugins dependency even further. We migrated the app to Rails
3.1 last year with the help of a number of gems that provide backward
compatibility. Even though, it took much longer than what we planned. Majority
of the files, be it models, controllers or views, had been touched and
changed. The worse part was that we didn't have sufficient test suites to
assist so lots of manual tests. Along the way, we gradually replaced those
obsolete plugins/gems one by one, which was a pain but seemed to be worth it.

Early this year we migrated the app to 1.9.3/3.2.x. Basically the same process
but less painful, as most of the gems/plugins issues have been ironed out last
year.

