Rails 1.2 RC1 and test cases

— November 23, 2006 at 09:06 PST


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?

9 commentsrails, sightings

Comments
  1. Rob2006-11-23 09:08:23

    sweet.

  2. Zach Baker2006-11-24 00:09:57

    I guess I needn't bother since I'm using ActiveResource, right? I've never used Simply RESTful so I can't just switch back. Otherwise, very cool.

  3. Jeff2006-11-24 02:12:54

    I'm no gem jedi, so a quick question. If I update to this RC using the given gem command, how do I get back to a normal stable system with stable updates after 1.2 final comes out? Thanks!

  4. Josh Susser2006-11-24 09:04:38

    @Jeff: the gem commands are pretty easy. Use gem list rails to find out what versions of the rails gem are installed. Then use gem uninstall rails -v VERSION to remove the version you want to get rid of. Or... after you install the final release of 1.2, use gem cleanup to remove old versions of gems.

  5. Tony2006-11-24 10:06:02

    Cool. Thx for not reiterating that fact =)

  6. Berto2006-11-27 06:37:00

    One thing worth adding to the article: RC1 lists as rails (1.1.6.5618, 1.1.6), so anyone checking the install should not panic because no 1.2 is visible ;)

  7. Scott2006-11-27 07:46:02

    So, if we are starting new development on a Rails app today, should we do it under this RC or start building under 1.1.6 and then later convert our code?

  8. Stephan Tual2006-11-27 07:58:39

    @Scott: that's not an issue - they are not breaking backwards compatibility, so there's nothing to worry about. If on the other hand you want to start a new app and plan to make use of the new features such as RESTful routes, then obviously you'd need to start coding from this RC onwards.

  9. Josh Susser2006-11-27 10:19:21

    @Scott: The only reason I can think of to start development on 1.1.6 would be if you knew you'd have to deploy on 1.1.6. Otherwise, go for 1.2. It's very stable, so you shouldn't have issues with being able to get work done. If you start on 1.1.6 you won't have much to convert, but some of the generators etc. will produce different code.

Sorry, comments for this article are closed.