commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Is there an missing bit in the instructions for making a release?
Date Fri, 15 Apr 2016 15:56:20 GMT
On Fri, Apr 15, 2016 at 11:54 AM, Ralph Goers
<ralph.goers@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 <bimargulies@gmail.com> wrote:
>>
>> On Fri, Apr 15, 2016 at 11:39 AM, James Carman
>> <james@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-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