Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: 
 <CAOGo0VZL_uGJJO+j3BHHZA8J4xnxO5aumwfZ8FF2Q5yQVZW+RQ@mail.gmail.com>
References: 
 <CALhtWkf0mEnTTLVEsPbZxm=S74JW4OCha6v9nhLAO+m9FGWqqA@mail.gmail.com>
	<CALhtWkd8Jn=5Rf1PVzT+i+ujCMXAPH_Gov5J8OcHEARAJcvLHA@mail.gmail.com>
	<CAOGo0VbEUdFbW6c=MVQMbXVqJMr3BdkfNWbyEBij=2Z=1soZBQ@mail.gmail.com>
	<CALhtWkce7BR1Dnc784Q8ZW4Gi+Xtcr=m9T+D+p6=DSA4c48pTg@mail.gmail.com>
	<CAOGo0VYaVt3hs6Nq-rUPryfEoVtpKAaUYgp+p9WuFUijHh_Zjg@mail.gmail.com>
	<CALhtWke9WJxwVJ8TWkCnbFST5aSN=kEuusOxwzfaX7QRMck5SA@mail.gmail.com>
	<CAOGo0Vb2JBy-J95aWBGG3zM-tB7JPQNPu1r5PZDXBpykqSLV0w@mail.gmail.com>
	<CALhtWkexyB8M4X=9aadDjn=RiOxW4kSdKkkhQ9A_AOVRHmkWvA@mail.gmail.com>
	<CAB3PPZrkJdLDTcPkAZ3B=Mas13pq-txjW3Yyvjb560qD0zierQ@mail.gmail.com>
	<CAOGo0VZL_uGJJO+j3BHHZA8J4xnxO5aumwfZ8FF2Q5yQVZW+RQ@mail.gmail.com>
Date: Fri, 15 Apr 2016 11:32:58 -0400
Message-ID: 
 <CALhtWkfGuK3xM8M9huRu8JLmPJotpssftZ-HjQXBT8DGX-JEKw@mail.gmail.com>
Subject: Re: Is there an missing bit in the instructions for making a release?
From: Benson Margulies <bimargulies@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 15, 2016 at 11:29 AM, sebb <sebbaz@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.worden@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 <bimargulies@gmail.com>
>> wrote:
>>
>>> On Thu, Apr 14, 2016 at 10:33 PM, sebb <sebbaz@gmail.com> wrote:
>>> > On 15 April 2016 at 02:19, Benson Margulies <bimargulies@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-unsubscribe@commons.apache.org
>>> >> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org