Near the end of a release cycle, you’ll often hear software developers talking a lot about dogfood. That’s been a major topic of conversation
among my coworkers for the last week or two. No, we’re not pet lovers. (Well, some of us are, but that’s not what’s relevant.) We’re just
shortening the phrase “eating your own dogfood,” which basically means using your own product before release to make sure it’s fit for release.

We have a public beta coming up in the pretty near future, and the release routine this time around is going as follows:

• Work and work and work to get a dogfoodable build.
• Have the whole crew dogfood (dogfeed?) while continuing development.
• Very shortly after the dogfood build, make what’s called a
  release candidate. This is an install of the software that you hope is
  good enough to release officially. It’s probably not good enough. If
  not, fix more bugs.
• Do another release candidate (these are traditionally named RC1, RC2, etc.)
• Finally, you have a build that’s good enough at least for a public beta, and you turn it loose.

So that’s what my company’s doing now. And I’m writing about it because I’m dogfeeding our browser to test features and see whether they’re
actually working. I’ve found two pretty major problems during the composition of this post, but by and large, the thing feels pretty good, and I’m getting excited about putting more polish on the product before our release.