Ruby on Rails 3.2: What's New, Release History & Support Lifecycle

What Is New in Ruby on Rails 3.2

How does Rails 3.2 improve development speed and routing?

Rails 3.2 makes the development environment noticeably faster by reloading classes only when the underlying files change.

• Class reloading is driven by config.reload_classes_only_on_change; set it to false to revert to the old eager reload.
• The new Journey routing engine speeds up route recognition, which is especially visible in large apps with many routes.
• Development mode now logs the query plan for any query that exceeds config.active_record.auto_explain_threshold_in_seconds (default 0.5 s).

In practice, teams see a 30-40 % reduction in request latency while working locally, and the faster route lookup reduces console startup time for rake routes.

What new Active Record features does Rails 3.2 add for query performance and convenience?

Rails 3.2 adds several Active Record helpers that let you diagnose and optimise queries without leaving the console.

• Automatic EXPLAIN: Queries slower than the threshold automatically call explain and log the plan.
• Relation#explain: Manually invoke Model.where(...).explain to see the underlying SQL plan.
• #pluck: Retrieves a single column directly from the DB, e.g. Client.where(active: true).pluck(:id).
• #uniq: Generates SELECT DISTINCT queries, e.g. Client.select(:name).uniq.
• #first_or_create / #first_or_initialize: Clearer alternatives to the old dynamic find_or_create_by methods.
• #with_lock: Wraps a pessimistic lock in a transaction, simplifying safe concurrent updates.
• store: Provides a simple key/value column for JSON-like data without a separate table.

These helpers reduce the amount of custom SQL you need to write and make it easier to catch missing indexes before they become production bottlenecks.

How does Rails 3.2 enhance logging and debugging for production applications?

Rails 3.2 introduces TaggedLogging and configurable log tags to make log lines more searchable.

• Enable tags in config.log_tags = [:subdomain, :uuid] and Rails will prepend each line with the subdomain and request UUID.
• The new ActiveSupport::TaggedLogging works with the existing Rails.logger and respects config.log_level.
• config.active_record.mass_assignment_sanitizer = :strict raises an exception on unsafe mass-assignment, surfacing bugs early.
• The DebugExceptions middleware replaces parts of ShowExceptions, giving you a cleaner error page and easier hook for custom error handling via config.exceptions_app.

In production, tagging logs with request IDs makes it trivial to trace a single request across multiple services, and the stricter mass-assignment checks reduce security regressions.

What are the major deprecations and breaking changes developers must address when upgrading to Rails 3.2?

Rails 3.2 removes several legacy APIs that will break older applications if not updated.

• Ruby version requirement raised to ≥ 1.8.7; Ruby 1.9.1 segfaults, so upgrade to 1.9.2 or later.
• vendor/plugins is deprecated; move plugins to gems or place them under lib/ with an initializer.
• Rails::Plugin and the old rails generate plugin command are removed; use rails plugin new instead.
• Setter methods like set_table_name, set_primary_key, etc., are deprecated in favor of self.table_name = style assignments.
• Implicit layout lookup when a parent controller defines a layout is gone; explicitly set layout nil if you need the old behavior.
• ActionController::UnknownAction and DoubleRenderError are replaced by their AbstractController equivalents.

Watch out for these changes early in the upgrade cycle; most teams spend a day refactoring plugins and updating model declarations.