18 February 2010

I shall be released!

Had one of those brain-cramping moments at work the other day. As part of our project, we have to use a tool developed by another team at our company. We were using release "1.0 RC1". Normally, an "RC" (release candidate) release means that the official "1.0" release is imminent, and should be identical to the "RC" release. But the other day, we were informed that support for a new feature will be available in: release "1.0 RC2". What??!?

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:































NameNumbering schemeDescription
Major releaseX[.0[.0]]Significant improvements through major rewrites. May not have an actual release number, but instead a distinct name.
Minor releaseX.M[.0]Introduces new features, but is mostly compatible with previous minor releases within its major release.
Maintenance releaseX.M.mUsually reserved for bug-fixes, may include minor functional improvements (like support for new devices or file formats).
Release candidateX.M.m RC-nSort of a "shakedown cruise". Note that there may be several release candidates, depending on how vigorous your beta-testers are.
Preview releaseX.M.m [Feature] PreviewAn 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 releaseX.M.m M-nA 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 releaseVariesA 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 buildX.M.m-YYYYMMDDUsually 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 buildVaries, possibly [Project name]-YYYYMMDD_HH:MM:SSAgain, 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?