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 installFollowed 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!