> On Aug 31, 2018, at 4:46 AM, Benedikt Ritter <brit...@apache.org> wrote:
>
> Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb <seb...@gmail.com>:
>
>> On 30 August 2018 at 11:19, Thomas Vandahl <t...@apache.org> wrote:
>>> On 28.08.18 12:03, sebb wrote:
>>>> On 28 August 2018 at 09:25, Mark Struberg <strub...@yahoo.de.invalid>
>> wrote:
>>>>>> This is unlikely to happen as long as it does not cover multi-module
>> builds
>>>>>
>>>>> The maven-release-plugin covers multi-module releases since many years.
>>>>>
>>>>> In the projects I'm working on there is no 'release manager'.
>>>>> _Everybody_ can do releases without having to know anything special.
>>>>> This is where the maven-release-plugin really shines.
>>>>> Just use mvn release:prepare + mvn release:perform and be done.
>>>>
>>>> If it works first time.
>>>
>>> I think the release plugin does quite a good job in resuming broken
>>> build processes, rolling back etc.
>>
>> Only for the RM.
>>
>> Meanwhile, trunk has been changed.
>>
>>>>
>>>> The problem is that the Maven release plugin design assumes that the
>>>> first release attempt will succeed.
>>>> As such, it updates trunk to the new snapshot version.
>>>> (This causes issues with CI builds)
>>>
>>> You are free to choose whatever developmentVersion should be recorded.
>>
>> It should not be necessary to downdate the new version.
>>
>>>> It also assumes that the current workspace does not contain anything
>>>> it should not.
>>>
>>> I actually consider this an advantage. It helps you to avoid
>>> inconsistent source trees.
>>
>> Huh?
>>
>> If a local workspace contains spurious files, by definition it is
>> inconsistent.
>>
>>> If you want to get around this, see
>>> checkModificationExcludeList of the prepare goal.
>>
>> Again, it should be the default to use a clean checkout of the tag for
>> building the binary/source artifacts.
>>
>
> Please note, that all what you are saying is just your opinion on how a
> release should be created. The maven team clearly has another opinion on
> that. Both are valid.
>
> Our release process is cumbersome and fragile leading to all release
> looking a little different from each other, depending on who is RM.
> The pain that our release process causes has been brought up again and
> again since I started here at commons back in 2011. I wonder whether it is
> a good idea to use a tool like maven that is pretty opinionated on how to
> do things and then bend it to do it another way. Maybe we should simply use
> maven the way it is intended. Or if we can't live with the way maven does
> things, maybe we should use a tool that gives us more liberty in
> customizing the build, e.g. gradle.
I’m a +0/+1 to migrating to the maven release process, assuming that you can
get it to work with the apache standards. The “commons-release-plugin” was
meant to reverse engineer (via automation) our current process. Fortunately, it
works fairly well.
-Rob
>
> Benedikt
>
>
>>
>>> Bye, Thomas
>>>
>>> ---------------------------------------------------------------------
>>> 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
