The theory behind a "release candidate" is that the code is done and ready for release (hence the name). All the bugs have either been fixed or documented, and you're just giving users a pre-release to see if any new bugs turn up in the field. The usual process is that if no major bugs are found, you'll just re-issue the release candidate as the final version. There can be trivial changes, like changing any embedded release IDs from "1.0 RC1" to "1.0" or maybe "1.0 FINAL", but absolutely NO code changes. Obviously, my company's suffering from a significant nomenclature failure. There's a term for what they're releasing, and that's a "milestone release". So why didn't they use that term? To quote the Tao (of Programming): "These are great mysteries."
I was fuming about this the other day, and I came up with a hierarchy of release types. Check these out and see if I've covered all the bases:
Name | Numbering scheme | Description |
Major release | X[.0[.0]] | Significant improvements through major rewrites. May not have an actual release number, but instead a distinct name. |
Minor release | X.M[.0] | Introduces new features, but is mostly compatible with previous minor releases within its major release. |
Maintenance release | X.M.m | Usually reserved for bug-fixes, may include minor functional improvements (like support for new devices or file formats). |
Release candidate | X.M.m RC-n | Sort of a "shakedown cruise". Note that there may be several release candidates, depending on how vigorous your beta-testers are. |
Preview release | X.M.m [Feature] Preview | An interim release to permit testers to play with some new feaure(s). Preview releases are intended to be used outside of the development team, so they should be relatively free of bugs, and any limitations should be clearly documented. |
Milestone release | X.M.m M-n | A periodic release, usually when some major new functionality has been introduced. Very similar to a feature release, the only difference is that feature releases are usually targeted at end users, and milestone releases are more oriented towards development partners or other allied groups. Milestones may be more buggy, or have the bare minimum of functionality required to "support" a feature. |
Interim release | Varies | A periodic release, usually just to the QA team. A work-in-progress, interim releases serve to aggregate bug fixes and incremental improvements. Some companies may require that nothing new be broken, but often there are no guarantees beyond the development team's assurance that the release represents their best effort to date. |
Daily build | X.M.m-YYYYMMDD | Usually only seen at sites employing Continuous Integration (CI), this is a build created from a snapshot of the development repository, often kicked off at midnight. May be used by QA teams, but often only monitored for regression test results. Numbering scheme varies, often a project code name is used instead of a release number. |
Latest build | Varies, possibly [Project name]-YYYYMMDD_HH:MM:SS | Again, usually only seen at sites employing CI. This is a snapshot of the current source repository. Absolutely NO guarantees about quality or function beyond the fact that it compiles (which can be a significant milestone in itself, sometimes!) |
So what sort of release hierarchy do you (or your team) use?