z-man: The web doesn't totally disagree with me.
At least, it's not incompatible disagreement. Maybe I'll make a little more sense. If a release is to have 0 priority 5 or higher bugs, then a release candidate must meet that requirement. So a beta can have any number of known issues, and we're wanting to collect more information on those known issues and also to learn of new issues that may be marked priority 5 or higher so they can be fixed. When a beta shows no priority 5 or higher bugs, has working installers for all platforms (including the generic binary release for Linux), then we recompile that same source as a release candidate. Possibly some minor changes with sanity check (for example if we were to change out the icon at that time, or the splashscreen, or suddenly rearrange config files in an otherwise harmless manner). Then the release candidate goes out, and hopefully no new priority 5 or higher bugs are found. All installers should already work, but will be tested again. Ideally, I don't think we'd do many release candidates, where might do 10 betas instead. A release candidate, to me as a user, means that the official release is just a few weeks away, so as soon as we make a release candidate, we're going to get flooded by players still playing the last beta because they don't want to upgrade until the official release (thus rendering them not testers anymore), and also by players expecting the release to come soon. So if we have to pack up and make another release candidate, we should have a very good reason for it. (a slight note on the page you linked, the definition given was in regard to commercial software) I seem to recall MPlayer angering a lot of people by running release candidates up to #8 for a year or so, and having to apologize with each one.About branches, I don't think HEAD is all that unintuitive. Most of our players aren't dumb, and even the ones that might be not all together are capable of understanding that CVS HEAD is the absolute latest dirty code, and that CVS snapshots are snapshots of HEAD without any sort of testing or QA attached. Ever since aabeta started up, I have encountered 0 players that think 0.2.8.0 is about to released (which is the contrary of what I encountered a few months ago, if y'all remember that....).
So, we release a beta, and doing so as soon as the branch is made is perfectly fine by me (need to tag it, of course). We direct users that the beta is the newest version, and that snapshots after the beta may be released to test specific bugfixes (say a player reports a bug with the beta, someone fixes it and makes a quick build to pass to the player to test it), but the beta is the newest official version and is the one we'll be supporting. We'll be supporting it by releasing another beta, of course.
We also direct users that the last "stable" release is still 0.2.7.1, so unless they want to become testers for 0.2.8.0, they should install 0.2.7.1 rather than the beta. Whether that's completely accurate or not is somewhat beside the point, because the point here is to establish that that's how we'll proceed, assuming of course that that's how we want to proceed. (We might point out cheekily that the beta might be a bit more stable than the last stable version, the cvs snapshot I've been running is, in fact, more stable than 0.2.7.1, or we might say "Normally the stable release is what you should download unless you explicitly want to betatest the new version, but for this release it looks like the beta is more stable than the last stable release, and hopefully with new releases we'll be 'back to normal'")Also, with the beta releases we might do dress rehearsal of the release process. z-man suggested higher up that a "release manager" should do the branch, tag it, then make the source tarball and distribute it to package builders. I figure that if all z-man does is whatever package he's volunteered to build and the source tarball and post them on sourceforge is good enough, the rest of us that intend to build packages can download from there and build. Tank or z-man are currently required to put up file releases, I think, but we can each post our packages somewhere for them to do so at their convenience, or possibly we might consider expanding to allow specific people to make releases (I think sourceforge allows you to designate who can make releases without explicitly making them admins).
In any case, I'm intending to do the Mandriva package and to try to build an autopackage spec file. Whether or not I'll build the generic binary linux release is going to depend on whether or not the binary built on my system will be able to function as a generic binary linux release, but we can release a beta built on my system to determine that. This depends on my own available time, though, and I still haven't had a chance to get back to making a new Mandriva snapshot.
see attached).
