views:

1258

answers:

7

I'm working on a Rails app that currently uses Rails 1.2, so I'm now quite a long way behind the latest stable release (Rails 2.3).

How should I go about the process of moving to a newer version of Rails?

Should I upgrade one point release at a time or straight to Rails 2.3?

How do I find out what has changed between versions of Rails, both

  • improvements or new features that give me more reasons to upgrade
  • Rails changes that will require me to modify my app before it will work with the new version.

(I have seen this question on the mechanics of upgrading, but I'm more interested in the process I should go through to make the upgrade as painless as possible.)

A: 

I shall start by answering my own question with the resources that I've managed to turn up with my Googling. The Rails 2.2 release note and Rails 2.3 release note give details of new and changed features in these two releases, but I can't find anything so definitive for earlier releases.

I also haven't found much about what will break when upgrading, apart from this release announcement which mentions that older versions of Passenger won't work with Rails 2.3.

David Waller
+1  A: 

I think there are some Rails rake tasks out there you could get that will look for deprecations in your app.

And as long as your app's in version control, I'd do the upgrade in one shot, and go through the error messages one at a time.

Also, aside from the release notes pages you saw for 2.2 & 2.3, there should be release notes or change logs in the source itself. Plus, you can search for blog posts (use google blog search) with search terms like "rails x.x.x new features", etc.

fig
+2  A: 

My advice is to spend a week paying down any testing debt you've accumulated, and then do the upgrade all in one fell swoop.

Where I work we upgraded a very large app from 1.2 to 2.0.2 last summer, and at the same time upgraded to Ruby 1.8.6.

It took MUCH longer than expected. The app used a couple of old features that were removed or deprecated (like ActionWebService), so converting those took some time. But mostly we ran into a lot of subtle bugs, like slight differences in how radio button params work, some of which were attributable to the Ruby (vs. the Rails) upgrade.

Some parts of the app had spotty test coverage. If we had gone into it with better tests it all would have been much easier.

Sarah Mei
+4  A: 

I went through this a few months back, did a lot of research and put together a rake task (based on someone else's script plus additional resources) that might help you in flagging things to change in your code. This was for upgrading to Rails 2.2 so it doesn't take into account Rails 2.3 changes:

http://gist.github.com/99535

Oh, be sure to check that the plugins and gems you use are Rails 2.x compatible and use the latest versions.

And I definitely agree with upgrading directly to Rails 2.3 in one go. And don't keep putting it off; the longer you go without upgrading, the more difficult it will be as more will have changed. And it's harder to maintaing Rails 1.x code as there are less resources that support it.

insane.dreamer
A: 

I found that those docs were missing a few details and moving from 2.1 => 2.2 took quite some time. Here are my notes:

Biggest time sink: assert_redirected_to has changed significantly, no longer supporting hashes (at all?)

Also, need to set environment/test.rb to disable forgery protection

If anyone's got news on these points for 2.3 that'd be super awesome.

Julian
+2  A: 

I've just started upgrading a Rails 1.2.3 application to a Rails 2.3.4 environment. The basic steps and caveats that I encountered are:

  • Create a skeleton application similar to your basic application
  • Check any environment.rb settings that you have in the old application to see whether these are required in the new version.
  • Migrate all the .rhtml files over to .html.erb; either using a script or manual. In my case there were 100+ files so automating it was way easier
  • Check any routes.rb changes that might need to be made given that RoR2.3.4 has simplified specifying the routes.
  • Make sure you have a good SCM system at hand; eg either Git, SVN or even CVS so that small incremental changes can be captured.
  • Check what plugins you need. In the beginning I simply removed all the plugins and in fact some were obsolete for the functionality that was to be implemented in the ported application.
  • Update any form_tag entries; for example <%= form_tag :action => 'search' %> becomes `<% form_tag :action => 'search' do %> otherwise you'll get some interesting error messages
  • Likewise change the <%= end_form_tag%> to closing the block as in `<% end %>
  • Check if you have any plugins in the 1.2.3 version which are now removed from the core and have to be installed as plugins and configured for dependencies. I had some issues with the in_place_edit and calls made to the calendar popup.

As others have said it can take longer than expected. I've done about 30hrs work on the migration. I had estimated it to take a lot longer; so that was good; but still have some more work on getting PDF generation going.

Just to make it more interesting the application was running on a MS-Windows environment; Ruby 1.8.7, Rails 1.2.3 and MS SQL Server. The aim was to migrate to a Linux environment; Ruby 1.9.x, Rails 2.3.4 and MySQL database so that involved the MySQl server database migration tools.

Grant Sayer
A: 

You've probably had plenty of experience with this at this point, but I ran across this while searching for a different Rails 1.2>2.3 upgrade question, and thought I'd toss in a little advice myself:

The biggest break I had in a relatively simple app was with Pagination. I found the Classic Pagination plugin to be a godsend for this.

Dan Sinker