ZOMG! We made it to the twentieth issue! Thank you for your support along the way, I wouldn't be able to do this without it!
My apologies to those who sat in front of their computer refreshing their inboxes last Friday. (Hopefully you've learned to not do that by now!) The Rails team have been working super hard in the last two weeks as we put in the finishing touches for the new releases, so I hope this is worth the wait!
This is going to be a very long issue! For those of you reading this with Gmail, you might have to click the "View entire message" link to read everything.
This week we pushed a beta release for Rails 4.2 with tons of new features. If you have been following this newsletter you probably heard about most of these already ;) Click through for the announcement blog post or read the release notes to learn more.
Also buried in the Rails 4.2 announcement blog post: Rails 5.0 is scheduled for next spring/summer, and it will require Ruby 2.2. This allow us to adopt the latest and greatest language features, such as keyword arguments. We can also rely on symbol GC and eliminate an entire class of security bugs!
If you haven't already, you should consider upgrading to 4.0.9 and 4.1.5 as soon as possible. These are security releases, which means that they contain only the relevant security patch and nothing else, so upgrading should be straightforward.
Earlier this week, we also did a maintenance release for the 4.1 and 4.0 series with lots of bug fixes. (Did I mention it was a busy week?) We have discovered a regression since, so you will probably see another RC releases soon™.
Active Job was one of the biggest features included in Rails 4.2. It is a queue abstract/adapter layer that enables developers (and gem authors as well) to schedule background jobs using a uniform API across all Rails apps without worrying too much about the backend (e.g. sidekiq or resque). (By default, it ships with an inline runner that executes the job immediately.)
The first use case for this feature is in Action Mailer: it now comes with a #deliver_later method that does what you would expect! (Consequently, #deliver is deprecated in favor the new #deliver_now.)
This pull requests makes the ETags generated from Rails smarter: by including the digest of the corresponding template in the ETag, Rails will know to invalidate the cached content when the template has changed. (This is relevant when you generate an ETags from the controller, as opposed to those automatically generated by Rack::ETag.)
Currently, Active Record only log errors that happened in after_commit and after_rollback callbacks. In Rails 5.0, this behavior would change to simply bubbling the errors, maintaining the parallel between other types of callbacks. To ease the transition, you can enable the new behavior today using a configuration flag in Rails 4.2 (or you will receive a warning otherwise).
This pull request adds #to_h to ActionController::Parameters which returns a new hash with any unpermitted keys stripped out. This is a compromise to migrate away from inheriting Hash in Rails 5.0, so you might want to take notes and start calling to_h on your params before calling Hash methods on it.
respond_with and the class-level respond_to methods have been extracted from Rails into the responders gem. If you are using this feature, you'll have to add that to your Gemfile when upgrading to Rails 4.2.
And that's it for this issue of This week in Rails. As always, there are a lot more changes on Rails than what I can cover in this newsletter, so I encourage you to check them out yourself!
If you have any feedback for me, please feel free to email me or let me know on twitter! Thank you for reading! <3 <3 <3