Bear's Log

Fritzy posted a comment that got me thinking about what exactly are “good habits” (aka Best Practices) for open source build/release projects and while I’m not going to outline them all here in this post, I do want to cover one item: the Release Candidate.

What is a Release Candidate? The Apache Incubator site has a guide that defines it as

Release Candidate

Collection of artifacts to be tested and voted on in order to release them. Sometimes folks use this term to refer only to a candidate source package.

and while that’s a rather dry wording, it does outline the most crucial piece: that it is a collection of artifacts (aka source files, images, etc.) that are to be considered for the next release. Those items are generated from a “frozen” source tree and used to test that the release candidate is ready for distribution.

In all but the extreme edge cases, a Release Candidate is a very specific thing that can only come about because the Developers and the QA team have decided that the current set of bug-fixes and/or new features are stable enough to be ready for consideration as the next release. This does not mean you can take the latest generated output from your continuous integration tool (or at worse case the tarball the developer was using as his test install) and move that to the web site and stamp a v2.0 sticker on it.

Only for the most basic of projects can you consider the developer version of a distribution to be ready for release - the vast majority of projects all have secondary information to be included and also will require additional changes to any number of support-related documents or sites. At the very least you need to create your ChangeLog to outline what has been fixed and what is new.

So a release candidate starts with what the developers have created, gets updated and massaged so that it contains the extra information that makes a distribution and then that part is tested in a non-developer environment. Once those tests are done can you consider it ready to be installed or distributed to the public.

The flip side is what things can cause a release candidate to not be considered - that in my opinion, is a very short list and depends on how the project defines “show stopper” so it’s hard to generalize into a post. The one item for me that is always an immediate veto is if it is discovered that code that isn’t part of a bug fix or a feature that was scheduled for the release is found to have been introduced. The reason why is really simple - how can you properly test code if you don’t have the bug notes or feature notes to guide you in testing.

That is basically a very fast overview of what I consider a release candidate to be. I’m going to work on an outline for what I think are the core tenets for any open source project and start a blog post series covering them.

thanks!