Hi, I agree that the key thing here is that your releases have to be approved according to [0], from the ASF's point of view that's all.
This means that before you publish the release artifacts the apache.org archive of this list needs to contain a documented trace that shows that you indeed got at least three +1 votes from PMC members, and less -1 than +1 votes on the artifacts that you released. It is indeed the responsibility of the release manager to ensure that this trace exists before releasing the artifacts, and to document this here in a [VOTE][RESULT] message that closes the release vote. This whole business of RCs makes that much more complicated than it should be IMO...in all the Apache projects where I've been active, releases are just discarded if they fail to get majority approval, or when the release managers feels that the raised objections warrant ditching the release. If a release fails to get majority approval, the release process starts over: create new artifacts, a new VOTE thread, collect those 3 +1s, tally the vote and you're good. Git or svn diffs will show how much changed between that new release and the one that failed, so re-checking the new release is easy: check the diffs between the new and old Git or svn tags and verify that the release tarball or other archive matches the content of those svn tags. Cast your +1 and you're done. So once again as per [1] my recommendation would be to not do release candidates anymore, consider each new set of releasable artifact as a new release, drop the releases who don't pass and publish those which do. Letting each (potential) release live in isolation should make your life easier. Like, dropping this discussion ;-) -Bertrand [0] http://www.apache.org/dev/release.html#approving-a-release [1] http://markmail.org/message/4ahntni6kzfnwjzw
