Sebb, I don't know why you think I could distinguish the following possible behaviors of prior RMs with a reasonable level of effort:
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
