On Fri, Apr 15, 2016 at 11:54 AM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Actually Benson, you can specify the tag name to use when you run the release > plugin. release:prepare has a tag parameter.
Thank you for addressing the specifics. If the -D for that had been in the web page to begin with, we would have been spared all this email. > > Ralph > >> On Apr 15, 2016, at 8:50 AM, Benson Margulies <bimargul...@gmail.com> wrote: >> >> On Fri, Apr 15, 2016 at 11:39 AM, James Carman >> <ja...@carmanconsulting.com> wrote: >>> 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? >>> >> >> The maven-release-plugin is designed for a workflow which does not >> match up with this PMC's policies. >> >> The plugin's workflow is as follows: >> >> 1) edit the POM to contain the release version. >> 2) check that in. >> 3) make an SCM tag named after the release version. >> 4) edit the POM to the next snapshot. >> 5) check that in. >> >> >> The problem is that this PMC does not want a tag named after the real >> (not RC) version to come into existence until after the vote passes. >> >> However, the vote has to result from testing of the one and only >> source archive that makes up the one and only legal release. So the >> pom in there has to have its final form before the vote. >> >> POMs contain, in effect, two versions: the <version/> element, and the >> SCM tag. Some of us prefer them to be consistent. Sebb proposes to >> escape this dilemma by allowing them to be inconsistent: >> <version>2.5</version> while the SCM tag says 2.5-RC4, which will, >> after all, point to the same revision/commit. >> >> That's the reason for all the email. >> >> --------------------------------------------------------------------- >> 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
