What is with everyone's aversion to using the Maven Release Plugin? I realize that it may not do exactly what we need out of the box, but it's a very useful tool. At home, I push a button in my Jenkins setup and it cuts a new release to the Nexus OSS staging repository awaiting me to finalize it. Can we not do a process like that? Perhaps we just create our own variant of the release plugin in commons to do our release process?
On Fri, Apr 15, 2016 at 11:33 AM Benson Margulies <bimargul...@gmail.com> wrote: > On Fri, Apr 15, 2016 at 11:29 AM, sebb <seb...@gmail.com> wrote: > > Thanks! > > > > It also occurs to me that having the RC tag in the POM is not > > necessarily a problem. > > > If you prefer to modify the doc to tell people how to use the plugin > so that the net result is the RC tag in the POM, OK. That satisfies my > ask for a set of instructions that an RM can follow without getting > into a controversy. > > All this will be moot if some other voters don't show up. > > > > > > > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
