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.