commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Is there an missing bit in the instructions for making a release?
Date Fri, 15 Apr 2016 15:29:05 GMT
Thanks!

It also occurs to me that having the RC tag in the POM is not
necessarily a problem.

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


Mime
View raw message