As a practical matter, it will be a while before I jump to 3.0. I am almost entirely on Rails 2.3.5 and Ruby 1.9.1 and that is working for me. Really it is a tradeoff between working at 100% speed right now or spending some time migrating to better tools.
I've pretty much switched everything to Ruby 1.9.1 and the first Rails 3.0 beta. Works like a charm. That's why I was so disappointed to see the 3.0pre2 rely on Ruby head rather than current Ruby stable (1.9.1).
As a matter of general principle I agree with this, but I've had so many problems with 1.9.1, I moved to 1.9.2-pre, and it's been working a lot better.
"This one spins out a few overdue extractions into plugins"
This has happened to me several times -- upgrading to a new Rails release breaks my app because things have been removed from Rails. Granted, a simple plugin install usually fixes said issue, but it's weird to me anyway.
I would expect code to be improved and proven in a plugin, then ultimately integrated into the framework. Rails tends to do the opposite for some reason.
We removed error_messsages_for because it wrapped up something really simple (iterating over error messages) into a something that seemed magic and hard and was impossible to change.
It also violated a core Rails statute of never dictating look'n'feel of the end application. The error_messages_for included both fixed copywriting, HTML structure, and relied on CSS. Ugh, bad shit.
We've replaced the output in scaffold with the unfolded iteration. As you'll see, it's incredibly simple.
This is one of my favorite things about Rails and the Ruby/Rails ecosystem. Removing features is viewed as a good thing. You might have to install a simple plugin but for all the users who don't need it that's a bit of code that they don't have to download, install, and run.
The feature I'm thinking of is/was (I thought) a core feature of the form helpers -- form.error_messages and error_messages_for.
I think since the beginning of Rails' inception, this feature has been included in scaffolding, shown in docs, etc. I would expect most Rails apps to use that particular feature.
I think you've just proved the point. I never use the form helpers, and do most form-like things through custom javascript and AJAX calls. Including form helpers is a waste of space for me.
Not everybody builds Rails apps the same way. I think that this flexibility is one of the framework's strengths.
The goal here is to slim down Rails as much as possible. A slim Rails means fewer moving parts, and an end product that's easier to comprehend. "Batteries included" sort of features are candidates for extraction.
while i do agree with the thoughts leaner, smaller, modular is better.. one of my main issues with rails has always been upgrading from releases have always been a painful thing to do. It was much worse pre rails ~2 , but in general as a lean start up.. its just such a pain point, that I do wish for more stability, and better planning of deprecation of features.
If we need what we were going to do before we did it. We'll, we'd just do it then and there.
Ruby code is simple enough that the process from good idea to implementation is small. That makes road maps meaningless because you can only map what you know. And if what you know can be turned into code instantly, why not do the code directly instead of writing down that you're going to do the code in the future?
We do deprecate everything gracefully, though, and there'll always be a good alternative to go to. For error_messages_for, all you need to do is add 1 line to your Gemfile and you're all good. Not exactly shattering.
If you find other, specific places where backwards compatibility is broken without proper deprecation or with a suitable plugin to carry you over, please report. We consider that a bug.
AFAIK, 1.9.1 incompatibility was due to a fault in Ruby itself, rather than Rails. And even though it seems to work with 1.9.2-head, that does have some major issues, like SEGV/Bus errors in native classes and gems alike (see http://redmine.ruby-lang.org/issues/show/3132)
