A lot of free software projects do release candidates, so you’ll see 1.9-rc1, 1.9-rc2, 1.9-rc3, …
I have never thought these were a good idea.
You are relying on getting testers, but getting people to test things is difficult (because it’s boring and hard). When you finally release
2.0, it’s like you’re declaring there are no bugs. Given that (a) software is intractably hard to test and (b) it’s hard to get testers anyway, it’s unlikely that
2.0 will be bug free.
libguestfs takes what I think is a better approach. In 5 days time I will fork whatever we have in development and I will declare it
stable branch, release 1.12.0. That’s not going to be a stable version, and we don’t pretend it is.
Over the days, weeks and months that follow, we backport patches to the 1.12 branch, following rigorous rules. This makes the stable branch more stable over time. It converges on greater and greater stability as we fix more bugs, more conservatively. In libguestfs, some branches get fixes for 7 months and counting (git shortlog).
The elements that I think are important:
- Don’t do release candidates
- Don’t rely on getting testers
- Do use stable branches
- Don’t develop on the stable branch (develop on the head and backport)
- Do have strong rules about what you backport
- Do backport conservatively, and be more conservative over time
- Do use git cherry-pick!