This week marked the release of Ruby on Rails 2.3 RC 1.
If you’re thinking, “Good Lord, that was fast. I just got around to watching the What’s New in 2.2 video”, you’re probably not alone. 2.2, according to the ever-reliable Wikipedia, was released about 10 weeks before 2.3 RC 1. And it’s not like 2.3 is a minor tweak — it includes a major change to the Rails internals (Rack support), a nested form feature that’s been a top request for some time, and a bunch of other small, but nice changes.
However, I don’t mean to do a “What’s New” post — at least, not this week. This week is a little bit more meta, and might more accurately be called, “How To Deal With What’s New”.
Keep an Eye Out
I have three or four big go-to sources for keeping up with changes to Rails. There are two blog sources that regularly post about changes in Edge Rails, the official Ruby on Rails blog, and Ryan Daigle’s blog, both well worth your time.
For keeping up with changes in the Rails ecosystem, especially new and updated plugins, the Rails Envy podcast is a great source. It’s about 15-20 minutes a week, there’s usually at least 2-3 things I need to follow up on right away.
Finally, if you want to go to the source, you can follow Ruby on Rails at Github. This will give you an RSS feed of all commits to the Rails source, and any comments on those commits. That’s a lot of information, I generally just keep an eye on this feed for things that seem particularly interesting.
Keep a Hand In
On of the side effects of keeping a low-key side project floating around is that it gives you an opportunity to have an actual project running Edge or new versions of Rails. Keeping the project on Edge is fairly easy if you are using Git and keeping Rails in it’s own separate git project (just a git pull from time to time). Otherwise, you can stay on Edge by periodically running rake rails::freeze::edge, which will download the current edge Rails as a tar file. Specific, non-edge releases of Rails, (like 2.3 RC 1) can be downloaded directly from GitHub. You can also get the most recent release candidate version of Rails as a gem by gem install rails --source http://gems.rubyonrails.org.
Know When To Tune Out
My basic rule of thumb on what version of Rails to use.
- New projects headed for real production should use the newest version available. If the project is just starting, and there’s a recent Release candidate, use that on the assumption that the release will be final before the site goes into production.
- Running a production project on Edge should only be done if there’s a specific feature in Edge that would be useful, and you’re willing to take the risk that you’ll get breakage from time to time on update. I’ve done this — we ran a project on Edge when Edge was 2.0, and it was clearly coming close to release. We got by with it, but there was the odd day here and there spent digging through the rubble.
- Again, test or side projects should generally use Edge. I might hold off a bit at the current moment, since the new Edge is 3.0 unstable, and I might give that a few weeks to settle down.
- Updates that are minor releases (2.0 -> 2.0.1) which are generally security related, should generally be applied as they come out.
- Point release updates (2.0 -> 2.1) generally should not be applied to an app in production unless other work is going on.
- That said, I would generally update within the Rails 2.x line as part of a larger update to a production release. The Rails team has done a pretty good job of keeping compatibility moving up within the 2.x line, and new features would be useful in any larger development.
- Remember, when you update, to run
rails .or one of the rake update tasks to get updated versions of the scripts, and JavaScript libraries, environment files, and whatnot in your existing app — you can get some weird bugs if the environment files are out of sync with the Rails version
Keep on the same page
Make sure that all the developers on your team are up to date on the features of the Rails version that you are using. If, say, half the team knows about named scopes, and the other half doesn’t, you’re going to get some messy, two-headed code. Running through the various What’s New docs as part of the kickoff on a new project might be helpful.
“Point release updates (2.0 -> 2.1) generally should not be applied to an app in production unless other work is going on.”
Hopefully this is going to change in Rails 3.0 as the design teem has committed to a stable and tested public API like Merb has. This should help projects stay compatible with point releases as long as they follow the API and don’t Monkey Patch things too much.
On a related Note, here hoping that Rails 3.0 will also be easier to extend (a la Merb).
Thanks a lot for the podcast mention! I agree with you mostly about the different versions of Rails to use. One thing I’d like to add is that if you’re using RSpec for testing, it’s generally a good idea to stay away from edge if you plan on updating edge frequently. I’ve lost a lot of time from a broken edge RSpec/Rails combination. HOWEVER, the good news is that keeping RSpec working with edge is going to be much more of a priority from now on, according to Yehuda. Anyway, great post!
[...] post is the practical companion to my post about a month ago about keeping up with Edge Rails and new versions. There are many wonderful things about Rails and [...]