> On the other hand, apparently large, busy sites are being built in 
> Rails right now.  And DHH has been very good at alerting people to 
> breakage and what to do to alleviate it.  So the issues may not be so 
> bad for so many people.

Rails had a huge change going from 0.8.x to 0.9.x. It required a whole 
manual to do that upgrade. It also improved the framework dramatically 
(Thomas Luekte cut 1,500 lines of code from his Snowdevil e-commerce 
application taking it from 7.5 to 6 KLOC).

Since the release of 0.9.0, though, updates to Rails have caused less 
than 10 lines of code change to existing applications. And they've been 
spelled out in the release notes.

Luckily, it's incredibly easy not even to bother with those changes if 
you have a finished application. Just lock it to a particular set of 
gems or to a particular SVN revision if you're using svn:externals.

Rails have not yet entered maintenance state. So currently, having a 
cleaner API for the future is more important than avoiding any kind of 
backwards compatibility breakage. If you'd rather work with a framework 
that reverses that value statement, I believe there are plenty to 
choose from.

It is my ever humble opinion that choosing Rails is well-worth 
migrating 10 lines of code to move through the 0.9.x releases. So I 
found statements like "Rails shouldn't be promoted before 1.0" half-way 
funny and half-way insulting. I'd argue that if nothing else, the time 
freed up from not having to do many of the tasks Rails intends to 
relieve you off should provide plenty of buffer to 1) stay informed of 
documented breakage between releases and 2) apply the outlined fixes.

> But the OP also appeared distressed that many new applications (e.g., 
> Rails) required 1.8, and that new apps not running with old versions 
> of Ruby was perhaps a significant problem; opinions vary.

I can only speak for myself personally, but I'm not interested in 
working with a 2 year-old version of Ruby in order to make it easier 
for some potential users to stay put because they can't upgrade for 
various reasons. Languages, frameworks, and applications are constantly 
faced with decisions that might decrease their market potential. As 
long as they're chosen consciously, it's part of the bargain.

Hence, I choose consciously to officially support only the latest 
stable release of Ruby for Rails. Given that releases are a year in 
between, this is a reasonable trade-off for me to make. This doesn't 
mean that Rails won't necessarily work with 1.8.1. Just that I'm not 
taking any special efforts to make it so. And that if your bug isn't 
possible to replicate on the latest Ruby version, then I'd happily 
accept a non-intrusive patch, but that's the extend of the service.

And I must admit that by the rate of growth experienced in the Rails 
community, I'm not currently looking for leverages to increase that 
growth by accepting more responsibilities, such as stricter 
non-breakage obedience.
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://macromates.com/       -- TextMate: Code and markup editor (OS X)
http://www.loudthinking.com/ -- Broadcasting Brain