4 ms·

Upgrading a Rails 2.1 app to 3.2 (slidedeck)

27 points by derwiki 14y ago

lloeki 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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.
    - lloeki 14y ago
      Thanks for the valuable feedback. We're not quite there yet so we might change the order of things.
  - dansingerman 14y ago
    But a lot of those shiny toys are probably going to be barriers to upgrading to a later rails version. "Be careful about adding gems, especially those with dependencies" and "Wooo - shiny toys" - are somewhat contradictory.
alexyoung 14y ago
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 14y ago
  > 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 14y ago
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.

27 points by derwiki 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
  - lloeki 14y ago
    Thanks for the valuable feedback. We're not quite there yet so we might change the order of things.
- dansingerman 14y ago
  But a lot of those shiny toys are probably going to be barriers to upgrading to a later rails version. "Be careful about adding gems, especially those with dependencies" and "Wooo - shiny toys" - are somewhat contradictory.

alexyoung 14y ago

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 14y ago
> 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 14y ago

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.