ok, there seems to be some confusion about the different ways to prepare, label, and vote on releases. here's my understanding of the two most common options.
1) How we used to do it. We would put the quality/status of the release in the release name. These would typically go something like 1.5-beta1, 1.5-rc1, 1.5. If a second beta or RC was necessary, then those would end with a "2". The proper way to begin this release process is to build the distribution with the anticipated release name (say 1.5-beta1) and upload it to where dev@ folks can get it. This is what i would call the test build. Once this test build is available, then call for a simple +1 (release it), 0 (i'm ambivalent), -1 (don't release) vote. This is a perfectly valid process, though it has the disadvantage that the quality/status of the release cannot be changed even if our opinions of it have changed for better or worse. If 1.5-rc1 turned out to have no problems anyone found or cared about, then we would still have to rebuild a release named 1.5, upload the test build of it, and then vote to release it, even though the only needed change was in the name. The improper way to do this is to call for a vote before providing the build for people to test. Henning initially did this with 1.5, and i did it for both Veltools 1.3-beta1 and Veltools 1.3-rc1. That was the lazy, improper way and won't be done again. However, for Henning's second try at 1.5, he did provide a proper test build for us to download and try before voting. 2) How i'd like to see us to do it. We would not put the quality/status of the release in the release name. Instead, the release is only given a number (typically in X.Y.Z form, but there's no reason for that but convention), and the quality/status of the release is decided by vote and labeled on the website and not in the release itself. The proper way to begin this release process is to build the distribution with the current release number and upload it to where dev@ folks can get it. This is, again, the test build. Once the test build is available, the release manager calls for a vote on the quality of the build +1 (GA), +1 (Beta), or +1 (Alpha). I don't really see much point in have a +1 (RC) option, but some like it. Once the vote is over, the release may be made available with the quality determined clearly labeled on the download page and in all announcements. This means that we don't have to do a new release if an RC is found to be perfect. All we have to do is re-vote, change the website, and announce it (if we want). It also provides a clear means to demote releases in which serious problems are later found. This ease of changing status makes it easier to have more frequent releases, and helps to ensure that the work of doing a release is not voided by a -1 vote. Instead, the quality just gets lowered, but the release still happens and is available to those who want it. We've discussed switching to 2), but i'm not aware of a clear decision or consensus on that, so it feels like we're still talking about both, hoping that one or the other will work better for us here. I really want to move to 2), but i've seen on other projects that the switch takes some getting used to. It may be best if we stick to 1) until Velocity 1.5 and Veltools 1.3 are out. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]