Nested Model Forms are a timely addition. When I was learning Rails, I always kind of assumed forms could work more like this. More information: http://weblog.rubyonrails.org/2009/1/26/nested-model-forms

The 2.3 release seems to go a long way to limiting the amount of configuration required for all sorts of these slightly-bothersome tasks, which is really nice.

It's been cleaned up a bit since that was posted. The release notes have a nicer, more concise example:

http://guides.rubyonrails.org/2_3_release_notes.html

Is it me or has the development of Rails accelerated drastically lately? It used to feel quite slow, and now it's very fast. Is it because they switched to git? Any core developers here?

I would say there are a few factors responsible for this. First, Jeremy Kemper got hired by 37signals which seems to give him a lot more time to work on Rails.

Next, around the time of the move to git, the existing Rails core team was shuffled a bit. Older members were retired (http://rubyonrails.org/core/alumni) and more active contributors (Josh and Pratik) were added to the team.

Then you've got the Merb merger which brought in Yehuda who works full time on Rails now, afaik.

If you look at http://github.com/rails/rails/commits/master you'll see commits from Josh, Pratik (lifo), and Jeremy, while http://github.com/rails/rails/commits/3-0-unstable shows commits from those three, Yehuda, and Michael Koziarski (who is still quite active).

Not to mention Rick Olson and all the patches from contributors, which now make their way more easily into core thanks to the streamlined contribution process and more active 'gatekeepers.'

So fresh blood, more time, easier to contribute, and exciting new ideas would be my guess.

One of my favourite graphs for explaining the power of git is the Rails traffic graph at github: http://github.com/rails/rails/graphs/impact . Track right until the beginning of April '08. That's when Rails moved to git.

Are you sure that's not just presenting the "authorship-preserving" nature of git, rather than a significant increase in contributor diversity?

Note that as contributor diversity appears to increase, LoC/primary contributor decreases.

Can a Rails person tell us if this is a big deal or not?

The templates feature ("start every Rails project with a default stack") is a godsend to folks who routinely start new projects, such as freelancers with quick turn around times or internal IT folks who crank out mini-applications.

I do a bunch of little utility projects for work (e.g. "Report X was previously generated based on five Excel files which had to be manually synched and executed, now the information is in one place on the intranet and updated every night via a cron job.") When you have a project which takes under a man-week a significant portion of the time is "Oh bloody heck I didn't install the auto-complete gem", "Oh bloody heck I forgot I'd need Google charts again.", "Oh bloody heck where did I put that syntax highlighter plugin", etc.

This lets me spend less time fighting Rails configuration and more time fighting Java XML configuration, like God intended.

Yes, this is a great innovation, and really according to the Rails Way. My favorite among the new features (and the other ones are good too.)

Now combine this with GitHub (search for rails-templates) and you've got a evolutionary algorithm for discovering the best rails default stack.

First of all kudos to all Rails contributors, this seems like a great release.

I agree the template feature is great, though at the moment not surprisingly a bit immature (template_runner.rb changed a lot in the last month, we'll see were it goes from here). I've been working on a template for a few days now (which will provide out of the box authentication with authlogic and sensible defaults for most things we usually use, like I18n, application wide settings, ubiquitous gems and plugins, SCM setup). I can see this feature saving us a lot of time on smallish projects.

Just curious, what gems do you use for those sorts of projects? Any of them on github to learn from/check out?

Some of the gems worth checking out (you can find most of them on github):

* authlogic for authentication

* openrain-action_mailer_tls for using smtp with tls with ruby <1.8.7

* mislav-will_paginate for pagination

* rspec/rspec-rails/shoulda for testing

* settingslogic for application configuration

* haml/sass for templating

Also some useful plugins:

git://github.com/Bertg/i18n_action_mailer.git (i18n support in mailers)

git://github.com/iain/i18n_label.git (translate labels)

git://github.com/thoughtbot/limerick_rake.git (lots of useful rake tasks)

I have about 15 that I keep coming back to. Most deal with boring business requirements: charting (I use two different variants of Ruby wrappers for the Google Charts API, plus OpenFlashChart 2), data entry, parsing, etc. I have no clue where they're hosted since I use Google as my own personal link memory service.

This is a significant release. Many of the changes include modularizing Rails' internals. This reduces Rails lock-in and keeps the core more stable.

I'm a fan of the performance tweaks in this one, but the important bits are the Rack integration and Ruby 1.9 compatability

Thanks for that. Is this the release in which Merb becomes integrated with Rails?

This is the first release to have major Merb influence. Rails 3.0 (possibly in May) will be the true merging of the projects.

I'm very excited for the confluence to occur. I've been looking around for a good web development stack to switch to for personal projects. I'm a .net guy during the day, but it's not enjoyable for me to work on.

I have basic proficiency with Python, but I don't care for Django and Pylons doesn't have very good documentation.

I am currently learning Clojure, but I get the feeling that I'd have to reinvent a lot of wheels to bring up a basic web development platform (on top of Compojure, I'd imagine). I plan on using Clojure down the road for some business logic I'm working on. It would be very nice to be able to keep all my heavy logic work in Clojure while using Rails on JRuby at some point down the road, so I think it's worthwhile for me to learn both.

It's good to hear that they are making so much progress on the Rails core in the meantime. It is starting to sound like a much more robust platform than it did a couple of years ago.

Perhaps some of the other Rails developers around here could satisfy my curiosity: when do you do the work (minor or major) to update your applications to use new releases? When the first or second RC comes out, or only once the 'official', final release is ready? Or are you tracking edge with an 'upgrade' branch or some equivalent?

Generally speaking I upgrade whenever I get the chance, but I always wait for an official release. Sometimes I let some of my smaller apps lag, but I try to keep fairly recent so as not to hold back any other apps that might be relying on major external requirements, such as Passenger ("mod_rails").

In the past I used to track edge, but that proved to be far too cumbersome.

I test against the RC releases and have found some bugs that way.

This time, it was testing mod_rails that led me to testing my apps against Rails edge. I wanted to make sure I could run mod_rails on open solaris in this next release cycle, so I was running things on edge earlier than I typically do.

Also, there was (is) an issue with Rails 2.3 and paperclip due to changes in how Rake handles empty file fields. There's been back and forth between the three projects on who needs to fix what. At the moment, the latest paperclip should work against Rails 2.3.

I always update when the first RC comes out. I figure I can do my part and submit bug reports that way, but I've never actually run into any bugs. The RCs have been totally stable. Go figure.

We've been branching to a 2.x tree and slowly adapting to the latest stable release (up until yesterday 2.2.2). Surprisingly plugin compatibility was not the biggest issue we faced (and we use many plugins) - most problems caused by plugins were solved by installing newer version. Our biggest problems come from subtle changes in HAML syntax, which causes syntax errors in a myriad of views. As you can imagine, it's rather tedious to hunt down those incompatibilities, as our application is rather large.