Jeremy, I think you know better, but you find this argument too convenient to give up. We did not "put Rails on hold". You could just look at the commit logs, but let me be more explicit.

* December 23, 2008: Merge announced

* March 15, 2009: Rails 2.3 released

* June 25, 2009: Rails XSS protection plugin for Rails 2.3 is released

* July 20, 2009: Rails 2.3.3 is released

* July 29, 2009: The first version of bundler (0.3.0) is released

* February 3, 2010: Bundler 0.9.0, the first "modern" version of Bundler, is released with support for Rails 2.3.5

* February 4, 2010: The first Rails 3.0 beta is released

* May 22, 2010: Rails 2.3.6 is released

* June 8, 2010: The first beta of Bunder 1.0 is released

* July 26, 2010: The first Rails 3.0 RC is released

* August 29, 2010: Bundler 1.0 is released

* August 29, 2010: The first Rails 3.0 final is released

As you can see, activity in Rails hardly ground to a halt during the time period we were working on Rails 3. We didn't even ship Rails 2.3 until three months after the merge, and continued active development for some time thereafter. And during this time, we backported two major new Rails 3 features, Bundler and Rails XSS, to Rails 2.3, actively releasing new versions of Rails 2.3 to take advantage of these backports.

Further, Rails 3 itself was a MAJOR feature release. Saying that Rails was "put on hold" for 2-3 (?!) years to merge in the Merb team is like claiming that Obama is going on an international apology tour. See below for a summarized list of important features.

I won't even talk about the improvements in Rails 3.1 or 3.2, which were possible because of the firmer footing we put the entire project as part of Rails 3 development. And this analysis doesn't even cover the major ways that the project structure changed during that time (full embrace of GitHub, significant increase in long-term contributors, acceleration of the guides project and other improvements to documentation).

---

Rails 2.3 was a major Rails release, with the following features:

* Completion of the Rack integration work begun earlier in the Rails 2.3 series

* Full integration of the Engines feature that was first softly integrated in Rails 2.2

* Localized views

* Support for public HTTP caching

* Ruby 1.9 support

* Nested Attributes (in both ActiveRecord and ActionView)

* Nested Transactions, even in MySQL

* A whole slew of other significant ActiveRecord improvements (http://guides.rubyonrails.org/2_3_release_notes.html#active-...)

* Unified rendering (render :foo, render "foo", etc.)

* HTTP Digest Auth

* Various performance improvements

* Rails application templates

* A whole lot else, see http://guides.rubyonrails.org/2_3_release_notes.html

---

Rails 3.0.0 was a major Rails release. Here are a few of the important features, but summarizing them all would be difficult:

* Incorporated direct support for Bundler, and drove the initial Bundler feature-set.

* Many architectural improvements, which drove improved, more stable third-party libraries in the Rails 3.x era (http://guides.rubyonrails.org/3_0_release_notes.html#rails-a...)

* A much bigger emphasis on eating our dog food: Rails 3 internals use exposed public APIs that any third-party extension can use. In fact, ActiveRecord itself is built as an extension!

* TMail, used by Rails 2.3, was unmaintained and extremely buggy (it often crashed when reading mail). The `mail` gem, written from Rails 3, is a ground-up rewrite.

* The ActiveRecord query interface is a night-and-day difference from the Rails 2.3 query interface. Users of ActiveRecord can now mix and match query parts (where clauses, group, order, limit) without having to worry about how to describe everything in terms of a single hash. This is probably the biggest change to the way developers use a major Rails component since the embrace of REST in Rails 1.2.

* ActionMailer finally got the update it needed. By Rails 2.3, ActionMailer had become a red-headed stepchild, sharing many features of the mainline render system on an ad-hoc basis. That meant inconsistencies galore. In Rails 3.0, ActionMailer got updated to share code and interface with ActionController, locking the two together to avoid another redheaded stepchild problem.

* Large improvements to Internationalization.

* ActiveModel makes it possible to use parts of ActiveRecord without using its SQL persistence layer. Apps have used this to spruce up plain Ruby objects, and libraries like Mongoid have used this to make alternate persistence libraries feel like the ActiveRecord people know and love.

* The router was completely rewritten, adding commonly requested features like the ability to match on any element of the request (commonly used for subdomain matching) and optional segments.

* The new ActiveRecord, ActionMailer and Router APIs maintained backwards compatibility with the older APIs until Rails 3.1 or 3.2, making upgrading plausible for more people.

---

Rails 2.3.3 was a minor update, with the following features:

* `touch` in ActiveRecord, to update a record's timestamp manually or automatically when associated records change

* Improved support for legacy schemas in ActiveRecord

* A general-purpose JSON encoding API and support for the `json` and `yajl` backends

* Other features: http://weblog.rubyonrails.org/2009/7/20/rails-2-3-3-touching...

Rails 2.3.6 through 2.3.9 (The Bridge to 3.0) was a significant update, with the following features:

* Direct support for the Rails XSS plugin

* Support for permanent and signed cookies

* Support for table-name-prefixes for all ActiveRecord classes in a module

* Lots of 3.0 ActiveSupport backports and improvements

* Improved support for Ruby 1.9

* See more at http://weblog.rubyonrails.org/2010/5/22/ruby-on-rails-2-3-6-...