I think this is a bit disingenuous. Ruby 1.9.0 was released Christmas 2007, 1.9.1 was released in January 2009, and 1.9.2 was released August 2010. Ruby 1.9.2 was the first release that most Rubyists considered "stable".
For the uninitiated, Ruby's tiny version is the equivalent of Python's minor version (Ruby 1.9.2=>1.9.3 ~ Python 3.2=>3.3).
Rails 2.3 supported almost the entire Ruby 1.8 series (except for one release, 1.8.3 I think, that had a serious bug). Rails 2.3 had experimental support for Ruby 1.9.1 when it shipped, but most people used Ruby 1.8.6 or 1.8.7, as Ruby 1.9 was still somewhat unstable at that point.
Rails 3.0 (which also shipped in August 2010) dropped support for Ruby 1.8 versions before Ruby 1.8.7, and shipped with stable support for Ruby 1.9.2. Ruby 1.8.7 shipped in May 2008, and was very compatible with Ruby 1.8.6. We (the Rails team) continued full support for Rails 2.3, which supported Ruby 1.8.6, until August 2011, when Rails 3.1 was released.
We have announced that Rails 4.0, which we still have not shipped, will drop support for Ruby 1.8.7. This means that we have dropped support for one version of Ruby (we will still support 1.9.2) in more than 2 years. That hardly qualifies as "New Ruby alpha? Deprecate everything!"
Short timeline:
- August 2006: Ruby 1.8.5
- March 2007: Ruby 1.8.6
- December 2007: Ruby 1.9.0 / Rails 2.0
- May 2008: Ruby 1.8.7
- June 2008: Rails 2.1
- November 2008: Rails 2.2
- January 2009: Ruby 1.9.1
- March 2009: Rails 2.3
- August 2010: Ruby 1.9.2 / Rails 3.0
- August 2011: Rails 3.1
- October 2011: Ruby 1.9.3
- January 2012: Rails 3.2
Releases of Rails 2.x all supported Ruby 1.8.2 and above. Releases of Rails 3 have supported Ruby 1.8.7 and Ruby 1.9.2 and above. The only change in Ruby support since Rails 2.0 was requiring at least Ruby 1.8.7 in Rails 3.0. There is an announced change for Rails 4.0, but Rails 4 has not been released yet, even in betas.
Rails is moving more quickly at adopting Ruby 1.9 than Django is at adopting Python 3, but that is because it was possible, from the get-go to support both Ruby 1.8 and Ruby 1.9 in a single codebase. That was not possible with the move from Python 2 to Python 3.
The typical argument I've heard about the difference is that Ruby 1.8 to 1.9 was a relatively smaller release. I think this underestimates the work that the Ruby team put into compatibility while developing Ruby 1.9, especially given the large encoding-related change made to Strings in Ruby 1.9 (Ruby 1.9 Strings are encoding aware, while Ruby 1.8 Strings are semantically simple byte Arrays).
Either it's a bug or I missed something. It could be that there were fundamental bugs in Ruby 1.9.2.
Again, Rails 4.0 is not out yet, even in betas. We're currently in the planning stages, with a lot of movement on master, so master is in a state of flux at the moment that doesn't really reflect what a release will look like.
Having investigated this a bit, it seems like there are a number of bugs in Ruby 1.9.2 (including some crashers) that make us want to steer people to 1.9.3.
All Rails core team members have running apps on the latest version of Rails, and Ruby 1.9.3 was the first version that everyone felt comfortable shipping to production with. So Rails 4 removes support for Ruby 1.8.7, and requires the first "stable" version of Ruby 1.9, based on our experience bringing apps to production.
For the uninitiated, Ruby's tiny version is the equivalent of Python's minor version (Ruby 1.9.2=>1.9.3 ~ Python 3.2=>3.3).
Rails 2.3 supported almost the entire Ruby 1.8 series (except for one release, 1.8.3 I think, that had a serious bug). Rails 2.3 had experimental support for Ruby 1.9.1 when it shipped, but most people used Ruby 1.8.6 or 1.8.7, as Ruby 1.9 was still somewhat unstable at that point.
Rails 3.0 (which also shipped in August 2010) dropped support for Ruby 1.8 versions before Ruby 1.8.7, and shipped with stable support for Ruby 1.9.2. Ruby 1.8.7 shipped in May 2008, and was very compatible with Ruby 1.8.6. We (the Rails team) continued full support for Rails 2.3, which supported Ruby 1.8.6, until August 2011, when Rails 3.1 was released.
We have announced that Rails 4.0, which we still have not shipped, will drop support for Ruby 1.8.7. This means that we have dropped support for one version of Ruby (we will still support 1.9.2) in more than 2 years. That hardly qualifies as "New Ruby alpha? Deprecate everything!"
Short timeline:
- August 2006: Ruby 1.8.5
- March 2007: Ruby 1.8.6
- December 2007: Ruby 1.9.0 / Rails 2.0
- May 2008: Ruby 1.8.7
- June 2008: Rails 2.1
- November 2008: Rails 2.2
- January 2009: Ruby 1.9.1
- March 2009: Rails 2.3
- August 2010: Ruby 1.9.2 / Rails 3.0
- August 2011: Rails 3.1
- October 2011: Ruby 1.9.3
- January 2012: Rails 3.2
Releases of Rails 2.x all supported Ruby 1.8.2 and above. Releases of Rails 3 have supported Ruby 1.8.7 and Ruby 1.9.2 and above. The only change in Ruby support since Rails 2.0 was requiring at least Ruby 1.8.7 in Rails 3.0. There is an announced change for Rails 4.0, but Rails 4 has not been released yet, even in betas.
Rails is moving more quickly at adopting Ruby 1.9 than Django is at adopting Python 3, but that is because it was possible, from the get-go to support both Ruby 1.8 and Ruby 1.9 in a single codebase. That was not possible with the move from Python 2 to Python 3.
The typical argument I've heard about the difference is that Ruby 1.8 to 1.9 was a relatively smaller release. I think this underestimates the work that the Ruby team put into compatibility while developing Ruby 1.9, especially given the large encoding-related change made to Strings in Ruby 1.9 (Ruby 1.9 Strings are encoding aware, while Ruby 1.8 Strings are semantically simple byte Arrays).