Thanks! It also occurs to me that having the RC tag in the POM is not necessarily a problem.
So long as the tag is retained after a successful vote, then does it matter whether the tag in the POM is IO-1.2.3-RC4 or IO-1.2.3 ? On 15 April 2016 at 16:02, Brent Worden <brent.wor...@gmail.com> wrote: > I probably won't be much help either as I have never used the plugin but, > there is a tag option for the plugin that might help control the SCM tag > that is used. Of all the options for the plugin listed on > https://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html, > the tag* options might meet your needs. > > > Thanks, > > Brent > > On Fri, Apr 15, 2016 at 5:16 AM, Benson Margulies <bimargul...@gmail.com> > wrote: > >> On Thu, Apr 14, 2016 at 10:33 PM, sebb <seb...@gmail.com> wrote: >> > On 15 April 2016 at 02:19, Benson Margulies <bimargul...@gmail.com> >> wrote: >> >> Sebb, >> >> >> >> I don't know why you think I could distinguish the following possible >> >> behaviors of prior RMs with a reasonable level of effort: >> > >> > As I have already said, I don't use the plugin. >> > However I have followed release votes and AFAICR the final tag never >> > been created before the vote completed. >> > In all cases I can remember, the final tag is created once the vote >> > has completed. >> > And I am pretty certain other RMs have used the release plugin. >> > >> > So it seems clear to me that something has gone wrong here. >> > >> > I don't know what, so I think we need input from an RM who has used >> > the release plugin. >> > They should be able to point out what is missing from the instructions. >> >> This started when I sent email two days ago saying that I was >> perplexed by the instructions. I only proceeded when no prior RM, or >> anyone else, answered. >> >> Maybe they used -DdryRun=true and then edited. Maybe I'm just being >> obtuse. We'll see. >> >> >> >> > >> >> 1: didn't use the maven-release-plugin >> >> 2: did use the maven-release-plugin and then used svn mvn to rename >> >> the tag it created >> >> 3: did use the maven-release-plugin, typed 'commons-io-2.x-RCy' at the >> >> prompt, and released with a pom with an incorrect scm element. >> >> 4: something else I didn't think of. >> >> >> >> I didn't volunteer to be an archaeologist, I volunteered to be a >> >> release manager.. >> >> >> >> At best, the doc is, as I wrote to start this conversation, >> >> incomplete, in that it does not give specific instructions for >> >> achieving the PMC's goals using the plugin. >> >> >> >> To me, the following sequence is inoffensive: >> >> >> >> 1: run release:prepare, creating a premature 'real' tag. >> >> 2: svn mv to convert that tag to an -RC tag. >> >> 3: svn mv again to convert it to a (conventionally) immutable 'real >> >> tag' if the vote passes. >> >> >> >> However, what I find inoffensive isn't important here. I'm not a PMC >> >> member here. If this PMC has a strong policy of tag immutability, then >> >> this PMC needs to document a procedure that both treats tags as >> >> immutable and creates completely correct poms, including the scm >> >> element that has to anticipate the eventual tag. It could create that >> >> policy by erasing any mention of release:prepare, or by filling in the >> >> missing details (though I continue to believe that there is no way to >> >> make it come out the way you want.) >> >> >> >> Believe me, if I ever RM another commons release, I won't use >> >> release:prepare until and unless someone writes up a step-by-step >> >> guide that leads me to do so in an acceptable way. >> >> >> >> If you examine the 'tags' directory in svn right now, you will see >> >> that it contains what I believe that you want it to contain: no >> >> commons-io-2.5 tag, but rather a commons-io-2.5-RC4 tag. So, I >> >> respectfully submit that we could proceed to decide if this release is >> >> good enough, and sort out the documentation later. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
