Benson, First of all thanks for bringing this up ahead of it being an issue. Definitely a good way to avoid problems.
How in option 3 do you go from 'x.y.z-RC1' to x.y.z? Is it because of the part "e"? If so how does this reduce to a low possibility the failure scenario? Does this just make it so the only remaining failure could be the maven release process itself (rather than input from community members)? I would personally be inclined to option 2. Can you share what you think are the drawbacks to option 2? Thanks Joe On Thu, Jan 15, 2015 at 9:23 AM, Adam Taft <[email protected]> wrote: > 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. > > >
