Last night, DHH announced the release of Rails 1.2 RC1. I predict we'll see a minor blogstorm of posts all reiterating that fact and talking about the new features. That's all fine, but this post is not one of them. Rather, it's a call to action for what to actually do with this release candidate.
For those not familiar with the term a release candidate is a development stage used in standard software development practices. (For those of you already familiar with the concept, please excuse this moment of pedantry while I catch everyone else up.) The point of a release candidate is to let the code bake for a bit while not making any changes, giving the development team a chance to find any lingering bugs. The developers are saying, "we think we're done, but lets make sure there aren't any showstoppers that we haven't found yet." In one sense it's an admission that test coverage is incomplete, but the world isn't perfect and neither is anyone's test suite.
When bugs are found in a release candidate, they are either deferred to a future release, or fixed and incorporated into a new release candidate. Bugs may be deferred if there are simple enough workarounds, or if the changes to fix the bug would be too extensive. That process continues until the development team decides the code is stable enough to release for real, or all get fired and replaced by a team of drunken monkeys who will release anything management tells them to.
OK, enough pedantry. If you want to know more about software development practices, buy a book.
So now what? Well, you've got a shiny, new release candidate. Time to find some bugs! You can easily install the gems in one line:
gem install rails --source http://gems.rubyonrails.org --include-dependencies
Or you can freeze a Rails project to the RC1 tag in subversion:
rake rails:freeze:edge TAG=rel_1-2-0_RC1
Note that RC1 isn't the same as edge trunk. Some changes in trunk aren't in RC1. Also note that if you freeze edge to the rel_1-2-0_RC1 tag, you'll have to re-freeze to a new tag when the next RC is made available.
Once you've got RC1 set up either as gems or frozen in your project, run your tests. (This assumes all your tests passed on Rails 1.1.6.) Then do the things you do to check out the parts of your app you don't really have good test coverage for. Come on, we know there are some. Maybe you want to go through a deployment cycle too. Anyway, play around with it and see how it works.
But what to do if your tests fail, or if something else goes wrong? File a bug on the Rails trac and put "1.2regression" in the keywords field. You probably want to look at the report first to see if someone has already entered the same bug, and just add a comment there if you have new information.
Now, here's the point of this whole post... When you create the ticket to report your bug, if by any means you can, include a failing test case. DHH said this at the end of his announcement, but it bears repeating. Test cases are important to help fix the bug, but also to create a regression test to make sure the bug never reoccurs. Incidentally, if your test case is incorporated into the Rails test suite, you get to say you're a Rails contributor. Isn't that worth the price of admission?