What is a “release candidate”?

There are some software version numbering conventions that people rely on a little bit. 1.1 is newer than 1.0. alpha is less solid than beta. The exact definitions of a move to 1.1 or from alpha to beta are variable from project to project. People do whatever works for their project, and that’s cool. As long as users can figure out what they’re downloading and have reasonable expectations, it really doesn’t matter.

I do have a bit of a pet peeve with the way a number of projects use the term “release candidate” (often appearing as “rc” in version numbers). Release candidate is very descriptive: it is a candidate for the final release. The idea is that you put the release candidate out there, make sure nothing silly crops up, and then tag that exact same code as the final release. That’s the whole point of a release candidate. That bit of code was thought to have been ready for final release and you’re just doing a sanity check.

Instead, I’ve seen projects that introduce fairly significant changes between release candidates. I just saw a project which has had rc6 out for 2.5 months! Release candidates should be followed fairly quickly by the final release (the bigger the project, the more leeway you’d likely need in the timing). It’s just hard to envision a need to wait so long and have so many release candidates. Unless, of course, it wasn’t actually a “release candidate” but rather just another beta.

Monkey with “alpha”, “beta” and “gamma” releases all you want, but at least recognize “rc” for what it is because it’s just plain English.

4 thoughts on “What is a “release candidate”?”

  1. Well, I may well be the guilty party with my WMI module. At least, even if it wasn’t the one you saw, it fits the bill. In my case, it was a combination of not really understanding the idea of a release candidate (or at least not thinking too hard about it) plus letting time get away from me.

    As a matter of fact, however, what do you expect to happen if problems crop up in a release candidate? Would the cycle go, eg: 1.0beta1, 1.0beta2, 1.0rc1, 1.0beta3, 1.0rc2, 1.0 final?


  2. I hadn’t thought about that aspect of not mentioning the “guilty parties” — people whose projects I hadn’t been thinking of would speak up. It wasn’t your project that I spotted…

    Here’s my thought on the line between beta and rc: you have 1.0beta2 and correct all known bugs there and everything’s looking good. You release 1.0rc1. Turns out that there’s a serious bug there, so you fix that and release 1.0rc2. If all is well with that, you tag it 1.0 final. So, it’s okay to hold up the final release and make another rc if there’s an important enough bug. A lot of people may get hung up on that “final” thing. You can still release a 1.0.1 if more things pop up, so final is not really the end of the line.

    I should note that the particular project that prompted this post has *new features* added between each of those rc versions.

Comments are closed.