On 15 April 2016 at 01:27, Benson Margulies <bimargul...@gmail.com> wrote: > On Thu, Apr 14, 2016 at 5:47 PM, sebb <seb...@gmail.com> wrote: >> On 14 April 2016 at 14:11, Benson Margulies <bimargul...@gmail.com> wrote: >>> On Thu, Apr 14, 2016 at 9:09 AM, Benson Margulies <bimargul...@gmail.com> >>> wrote: >>>> The instructions offer two approaches as equivalent: manual tagging >>>> and pom-editing, and the release plugin. >>>> >>>> If you just use the default options and hit <enter> a few times, >>>> you'll get the tag: commons-io-2.5, NOT commons-io-2.5-RCx. The manual >>>> process will, on the other hand, name the tag commons-io-2.5-RCx. >>>> >>>> It seems to me that the doc should mention this. >>> >>> However, there's more. The SCM elements in the pom will refer to the >>> RC tag, which is not what you want once the release is finalized. So I >>> think that the release plugin procedure has to be to let it create the >>> commons-io-2.5 tag, and then manually add the -RCx tag for the record. >> >> -1 >> >> That sounds backwards. >> >> The commons-io-2.5 tag should only be created when the RCn vote has >> succeeded. >> It is created by copying the successful RCn tag. > > > Sebb, I'm just following the doc as I read it. It tells me that I have > the option to run release:prepare. Release:prepare creates the tag you > don't like. There is no way to use that goal of that plugin that > avoids it; if you try, you end up with the wrong pom contents for the > actual release, and then you can't keep the signatures consistent. > > What I did, in fact, was 'svn cp commons-io-2.5 commons-io-2.5-RC4'.
Does the doc tell you to do that? Did commons-io-2.5 exist previously, i.e. did the previous RM create it? > If you like, I could svn rm the plain commons-io-2.5 tag until and > unless a vote passes, and then cp/mv from the RC tag to it to put it > back at that point. AFAIK others have used the Maven Release goal without prematurely creating the final tag. I have never used it so I don't know how they managed it. But if the only proper way to use the release plugin results in creating the final tag before the vote has even started, then the plugin is more seriously broken than I thought. > The doc reminds people over and over again that tags are, in fact, > _not_ immutable, which is why the email template carefully calls for > svn rev numbers. Tags aren't immutable in svn, and not in git, > neither. Every Apache project I've RM'd takes that into account. > People are constantly removing and recreating tags as votes fail and > succeed. If this PMC doesn't want to do that, it needs different > documentation. My point was that the final tag should be immutable; it should only be created once and then left alone. RC tags also should only be created once. Immutability is achieved by convention. > If you think that no one should ever use the maven-release-plugin on > the commons project, than as a PMC member, why don't you commit a > change to the doc to take it away as a procedural option, instead of > -1'ing me for following the doc? If the doc said, 'you must do all > the pom editing and tagging by hand', I'd have gritted my teeth at the > tedium, but I would have done it. Because others want to use the plugin and AFAIK have successfully used it without prematurely creating the final tag. > > >> >> If you create the 2.5 tag first, and create RCn from it,what happens >> when the RCn vote fails or is withdrawn? >> That implies the 2.5 tag will have to be deleted and recreated. >> But tags are supposed to be immutable. >> >> I don't use the Maven Release plugin myself, partly because of such issues. >> But others who do may be able to clarify the instructions. >> >>> --------------------------------------------------------------------- >>> 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
