Upgrading to Rails 4.2

The new 4.2 release of rails just hit RC3 and should be available for release before Christmas. So, I decided to take advantage of the new adequate record update and the fancy new active jobs interface for a project I am working on.

Here are the notes from my experience

Remember to set the correct gem version ... you dummy

If you were to say run rake rails:update without actually updating the Gemfile it would probably not actually do anything helpful. Probably.

This is actually the first step in the handy rails guide to updating rails. But if you happend to have a nasty head cold you might happen to skim over this part and imagine that the Rails Magic ^TM might just make it work for you ... hypothetically speaking. So do this first.

You will probably also want to do a

$ bundle update
$ bundle install

Followed by a

bundle outdated

So that you can determine which other gems you might want to update. I actually did this step last after updating rails so that I could get rails working first, then suss out any bugs caused by updated gems.

N.B. the project I'm working on is relatively small, so there wasn't a ton of regression testing that needed to be done in updating gems. YMMV

Diffs for days, er ... hours ... maybe an hour

After appropriately updating the Gemfile as in step 0, I now ran the appropriate rake rails:update task and it gave me all the shiny new rails files.

Then, I used my favorite diff tool (RubyMine) to compare the changes with the previous git commit.

Upgrade Issues

I was upgrading from a rails 4.0 project so I found a few things that were also updated in 4.1, which needed to be addressed.

Moving the asset paths

4.2 reccommeds moving asset related items to config/initializers/assets.rb. My project had a few directives scattered around the application.rb, production.rb and development.rb files, so I took the opporunity to move them to a more central location.

As of rails 4.1 app/assets/fonts is now included in the default asset path, so that can be removed.

I also took the opportunity to remove any config.assets.precompile commands for font files. appart from svg files, these are essentially binary files and don't need to be processed.

Keep your secrets elsewhere

config/secrets.yml is now the new place for the super-long super-secret string used in secure cookies. Gone are the days of config/initializers/secret.rb ... unless you are doing some kind of really cool automatic secret setting thing.

When config is not enough

I was also getting an error when trying to start the rails server
undefined local variable or method `config' for main:Object (NameError)

As it turns out you need to change things like
config.assets.precompile

to
Rails.application.config.assets.precompile

since you are no longer in the same context in the initializer.

Other Considerations

Web Console

The idea of the webconsole is interesting and is certainly a step up from the default error page. However, I've been using the better errors gem which plays nice with pry and looks a little more calming than the default ruby red error page.

Responding to the lack of response from respond_with

Until I read about it in the rails changelog I had never deigned to use the respond_with method in my controller or to use responds_to at the at the class level. However after reading this article and checking out the responders gem, it looks like something I might want to experiment with to eliminate some repetition in my controller code (even though DHH hates it).

That was about it. It was interesting to read through all of the configs and to eliminate cruft where it had built up over time.

Next time, more on active jobs!