Rails 3.2, released in January 2012, has received regular updates throughout the year – version 3.2.8 was released just a few weeks ago. The Rails/master branch has switched to version 4.0.0.beta last December, and a 4.0 release was tentatively scheduled for Summer 2012. While a new release date hasn't been announced yet, the picture of what will comprise Rails 4.0 is becoming clearer: In a presentation at Boston RB, Rails contributor Prem Sichanugrist gave an overview on the upcoming changes in Rails 4.0. The main features, also outlined in this draft of the release notes, are
- Ruby 1.9.3 only,
- Strong Parameters,
- Queue API,
- Caching Improvements.
DHH announced the decision to drop Ruby 1.8 last year, so this should come as no surprise and puts another nail in Ruby 1.8's coffin.
Strong parameters offer a way to deal with mass-assignment protection by moving it to where it belongs: in the controller and not in the model. The new approach makes it easier to filter parameters and is more explicit about which parameters are allowed. Additionally "parameters can be marked as required and flow through a predefined raise/rescue flow to end up as a 400 Bad Request with no effort". Strong Parameters can already be used in Rails 3.2.8 with a plugin.
The ActiveSupport::Queue inherits from the standard Ruby queue and runs the queued job in a background thread. A job is simply an object that responds to a run method. To make the testing easier, the queuing system is configurable and can be changed to process jobs synchronously.
Cache Digests is a new plugin that makes Russian-doll caching schemes easier to maintain. With the current approach, the version numbers of dependent templates need to be manually tracked down and bumped:
Enter Cache Digests: With this plugin, all calls to #cache in the view will automatically append a digest of that template and all of its dependencies! So you no longer need to manually increment versions in the specific templates you're working on or care about what other templates are depending on the change you make.
Rails 4 will also support the HTTP/1.1 PATCH method:
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. [RFC 5789] adds a new HTTP method, PATCH, to modify an existing HTTP resource.
The PATCH verb will map to the update method alongside PUT, so it will not break backwards compatibility. See the discussion in the Rails issue tracker for more information about motivation and consequences.
Other new features and changes include a cache for schema dumps, PostgreSQL array support, Routing Concerns to clean up duplicate routes and updates to ActiveRecord::Relation.
As always, new releases also deprecate outdated features. The release notes draft already contains a detailed list of deprecated components and methods. Some of these simply moved to their own gems, like ActiveRecord::SessionStore or ActiveResource. Prem Sichanugrist outlined the new deprecation policy in his talk: once Rails 4.0 is released, Rails 3.1 will be at end of life, and some 3.2 features will lead to deprecation warnings. These deprecated features will the be removed in the 4.1 release of Rails. This should make the upgrade from 3.2 to 4.0 smooth enough to pose no big risk.
A release candidate hasn't been announced yet, but will likely arrive before Christmas.