> Yes, you should call a vote expecting it to pass. Releases can't be vetoed, > so it > should be pretty serious objections to stop at that point. > > For the mechanism beyond that, it can go either way - communities I've been > involved in generally reach some consensus by testing RC labeled bundles > before voting on the final release. I find this helpful because otherwise you > get votes mixed in with issues and it can be hard to ascertain what the result > really is. > > I believe some others will vote earlier, and roll a new version number if the > vote fails. These are typically mature projects that tend to have their votes > succeed in most cases. > > I would avoid rolling 4.0.0 multiple times, as that is likely to cause > confusion > about which is the real one. > > Worth bearing in mind for the future too, you can certainly release > something and label it alpha/beta/milestone and then release the GA later. > Releases of source code don't attribute any particular meaning to its level of > maturity, QA or marketability other than how you choose to label it. >
Got it. Thanks for the explanation there. Looks like I jumped the gun on that call. I'll reissue this once the current bugs are done. --Alex
