Option 1 may also cause issues with downstream mirrors. For example, if you push a tag and it gets mirrored somewhere (say... GitHub) and then you delete and push a new tag, then the new tag may or may not be properly reflected in the mirror. It complicates things further if folks have forks of the GH repo, and their tags get out of sync. Now, generally this won't propagate anywhere relevant, but sometimes people will end up with strange errors that they won't be able to otherwise explain.
Mike On Thu, Jan 15, 2015 at 8:14 AM, Joey Echeverria <[email protected]> wrote: > The one thing I really like about the RC process is it makes it easier in > my mind to draw a line in the sand over when certain code changes are not > allowed. > > > Basically, when the RC process starts, the only changes allowed in that > release branch are issues that caused the vote to fail. > > > > > From an ASF perspective, the only things that matter for a release is > meeting the legal requirements. Having the RC process lets the technical > side of release voting to play out. > > > > > I don't personally like version skipping, but I don't feel any reason to > convince others. So long as the order of releases is clearly documented, > there shouldn't be any issue if y'all prefer option 2. > > > > > FWIW, in Kite we follow option 1. We stage the release and vote on it. If > the vote fails, we rollback the release and delete the tag. When we run the > release again, the maven release plugin recreates the tag. > > > > > -Joey > > > — > Joey Echeverria > > On Thu, Jan 15, 2015 at 6:48 AM, Benson Margulies <[email protected]> > wrote: > > > 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. > >>> > > >>> >
