Thursday, June 25, 2009

upgrading to Rails 2.3.2

I'll leave off all the general details that have been posted about preparing and upgrading to Rails 2.3.2, and cut to the chase on some issues we had getting iZoca up and running on 2.3.2.

As part of upgrading to 2.3.2 I was also considering taking a "lighter" but explicit approach towards dependencies. For the past few years, I've been all about freezing Rails versions, and even some core Gems that we use. Way, way back Rails didn't have as good a strategy as it does now (and has for some time now), at managing version dependencies. So for years the community has gotten behind the idea of freezing the versions that you are building against. I've been doing it for a while. But, in my never ending question to constantly challenge why I'm doing what I'm doing, I thought maybe it was time to challenge those thoughts again.

So, I set out on the path of a) upgrading to Rails 2.3.2 , and b) investigating the idea of no longer freezing Rails within my application. Instead I would specify the version of Rails and Gems in my config, and keep the application size smaller and at the same time convince myself if freezing was still necessary.

Freezing is still necessary.

So, I installed the official 2.3.2 Gem, specified it in my config, and did the same for all the Gems we had frozen. Updated the app, and worked through any normal upgrade issues. Even took the time to work through all the new warnings now introduced by 2.3.2. Was feeling pretty good.

Released things to a dev collaboration server, and things weren't so good. We have caching turned on there, and immediately we started getting some errors with:

uninitialized constant ActionController::Caching::Sweeper

A quick look in Lighthouse, and I found this  post: https://rails.lighthouseapp.com/projects/8994/tickets/1977-actioncontrollercachingsweeper-autoloading-is-broken

Sure enough it described our problem, and it appeared that there was already a patch for it. But, the patch was added to master sometime in May, and could be found in 2.3-stable, not in the official 2.3.2 release. 

So, we froze Rails to RELEASE=2.3.2.1 (freezing directly to 2.3.2 wasn't a good idea: http://weblog.rubyonrails.org/2009/3/20/this-week-in-edge-rails). Once we froze to RELEASE=2.3.2.1, I went github hunting for where the patch was applied, and to see if there were any other follow-ups in regards to this patch since then. I found 2:
http://github.com/rails/rails/commit/f7cb7fce4cb25e608f0c2d94a4970c0c7cb7d3da

http://github.com/rails/rails/commit/5ac05f15c6d8f496c4e152dbbecd8ccb12041770

I was able to cleanly apply these patches to my frozen Rails version, and successfully run Rails tests. 

Along the way, I took a sidestep to see how things looked running with the edge 2.3-stable version. I immediately had problems with my version of the Haml gem, and had to get their edge, and build a local gem. We also use the ar-extension gem for some bulk inserts, and it has some problems on Rails edge. It looks like the sanitize_sql method signatures, which ar-extensions overrides have changed in Rails and this was causing problems whenever that gem got loaded. There were also a number of our iZoca tests that were now failing to do changes in edge. So, we decided to go with the more stable approach of freezing to RELEASE tag 2.3.2.1 and applying the few patches we needed.

So, we are now up and running in development mode on 2.3.2 (ah, 2.3.2.1 to be exact), with a few additional patches.

...and, ah, I'm still digging and loving freezing Rails and Gems.

No comments:

Post a Comment