The most important part to consider is 'What can go wrong?'. In the case of making 1.0 and deleting if it fails, let's imagine the release then pauses. For example Collections 3.3. We would then have the possibility of a 3.3 tag that people would think meant something.
In the case of making 1.0-rc1 and declaring it good, let's imagine the releaser does a release and forgets to do the copy. In that case we have a release but the tag it came from is not clear. Neither good, but the latter is easily rectified with some mail archive digging. The former case we never hear about. So much as I like KISS, going with the 1.0-rc1 etc is the least confusing to the user imo. Hen On Sat, Jun 27, 2009 at 6:42 PM, James Carman<ja...@carmanconsulting.com> wrote: > The way I did it with Proxy was to create proxy-1.0-rc* tags and just > like sebb said, when the vote finally passed, I copied the successful > rc tag over to the proxy-1.0 tag. I think that's the best way to go > with respect to our release voting procedures in commons. > > On Sat, Jun 27, 2009 at 5:55 PM, Jochen > Wiedmann<jochen.wiedm...@gmail.com> wrote: >> On Sat, Jun 27, 2009 at 11:48 PM, sebb<seb...@gmail.com> wrote: >> >>> AIUI, the GA tag is created before the vote. If the vote fails, the >>> tag has to be deleted and recreated for the next vote. I.e. the tag is >>> not enough to identify the source of what was voted on. >> >> I agree with you that *release* tags are important and should be kept. I >> won't bother too much with tags that have been rejected. >> >> >>> Whereas if one uses a tag with RCn in the name, one can create RC1, >>> RC2, RC3 etc if the votes fail; whichever RCn succeeds can then be >>> copied to the GA tag, which is therefore not changed once created. >> >> And what prevents you to rename release => RC1, release => RC2, and >> so on, unto a successful vote? (Not that I'd request that, but it sounds like >> a good compromise.) >> >> Jochen >> >> >> >> -- >> Don't trust a government that doesn't trust you. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
