Some people hate option 2 because version gaps offend their sense of harmony. I'm not one of those people, I've just spent a lot of time around them. So, to clarify, if gaps don't bother this group, by all means, take (2). And edit the page I just created to say so, and to specify precisely what form of (2) you want: 0.0.1 -> 0.0.2 or 0.0.1 -> 0.0.1a.
Here's how the RC thing works out in practice. x.y.z-RC23 passes. You change _nothing_ except the version numbers in the poms. You go through the release procedure again. Something very sad has to be going on if that fails. On Thu, Jan 15, 2015 at 9:36 AM, Joe Witt <[email protected]> wrote: > 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. >> > >>
