Henri Yandell wrote:
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.
+1
Phil
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
