As a pessimist, I feel compelled to remind this group that we can expect the release procedure to fail from time to time. Either the build croaks in the middle of the maven-release-plugin, or someone testing the release finds a blocking problem.
When this happens, it tends to trigger a religious war about the management of git tags. I've lived through this several times, and I'd love to avoid living through it again. Let me describe three options: 1. Delete the tag and try again. If a release build fails after tagging, or a vote fails, delete the tag from the official repo and try again. 2. Abandon the version number. Once we tag 0.0.1, it's done. If it can't be released, there will never be an 0.0.1, we try again with 0.0.2. Or 0.0.1a. Or whatever. 3. Use release candidates to reduce the possibility of a problem to a very, very, small possibility. Option 3 is how the Lucene PMC works. I think, myself, that it's the best solution, so I'll detail it. Assume that the goal is to release version x.y.x. a. RM sets versions in poms to x.y.z-RC1-SNAPSHOT b. RM runs full release procedure, including vote, for x.y.z-RC1. c1. If the vote passes, that version is, in fact, _released_ in the Apache legal sense. c2. If the vote fails, the RM sets the versions to x.y.z-RC2-SNAPSHOT and returns to b. d. It cooks for a short period of time. e. The RM sets the version to x.y.z-SNAPSHOT, and returns to b. This procedure pretty nearly guarantees that a build or vote for x.y.z will never fail, so the community can choose between (1) and (2) above in a context where it will nearly never happen. What you cannot do is vote based on an RC and then set the version to a non-RC. This is a 'feature' of Maven.
