Historically, I think we've done more of "2. Abandon the version number."
Procedure "3. Use release candidates" is only needed if there's a compelling perspective that proper versions should have no gaps. I personally don't buy this so long as we document that there may be gaps (or it can be easily inferred). But you're right, there are holy wars about this topic. One of the obvious problems with "3." is the extra vote cycle required. At least for pre-1.0.0, this might be burdensome. Perhaps we could reconsider after 1.0.0? I personally don't like deleting things, so I don't favor "1. Delete the tag and try again." On Thu, Jan 15, 2015 at 9:11 AM, Benson Margulies <[email protected]> wrote: > 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. >
