On 2018-08-31, Benedikt Ritter wrote:
> 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.
+1
> Our release process is cumbersome and fragile leading to all release
> looking a
> On Aug 31, 2018, at 4:46 AM, Benedikt Ritter wrote:
>
> Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb :
>
>> On 30 August 2018 at 11:19, Thomas Vandahl wrote:
>>> On 28.08.18 12:03, sebb wrote:
On 28 August 2018 at 09:25, Mark Struberg
>> wrote:
>> This is unlikely to happen as
On 30.08.18 13:45, sebb wrote:
>> You are free to choose whatever developmentVersion should be recorded.
>
> It should not be necessary to downdate the new version.
It isn't. You can configure that.
> Huh?
>
> If a local workspace contains spurious files, by definition it is
> inconsistent.
Y
On 31.08.18 10:46, Benedikt Ritter wrote:
> 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 bac
Am Do., 30. Aug. 2018 um 13:45 Uhr schrieb sebb :
> On 30 August 2018 at 11:19, Thomas Vandahl wrote:
> > On 28.08.18 12:03, sebb wrote:
> >> On 28 August 2018 at 09:25, Mark Struberg
> wrote:
> This is unlikely to happen as long as it does not cover multi-module
> builds
> >>>
> >>> The ma
On 30 August 2018 at 11:19, Thomas Vandahl wrote:
> On 28.08.18 12:03, sebb wrote:
>> On 28 August 2018 at 09:25, Mark Struberg 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.
>
On 29.08.18 01:18, sebb wrote:
>> It doesn't check out the tag into a separate directory to build the release
>> artifacts?
>
> Last time I checked it did not.
The release:perform goal does this and always did. See target/checkout.
Bye, Thomas
---
On 28.08.18 12:03, sebb wrote:
> On 28 August 2018 at 09:25, Mark Struberg 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
On 28 August 2018 at 19:36, Matt Sicker wrote:
> On Tue, 28 Aug 2018 at 05:03, sebb wrote:
>
>> 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 buil
On Tue, 28 Aug 2018 at 05:03, sebb wrote:
> 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)
>
Would it work if you made a release branch first
On Tue, 28 Aug 2018 11:03:15 +0100, sebb wrote:
On 28 August 2018 at 09:25, Mark Struberg
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 'r
On 28 August 2018 at 09:25, Mark Struberg 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 release
On Tue, 28 Aug 2018 10:25:54 +0200, Mark Struberg 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 releas
> 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 th
On Sun, 26 Aug 2018 10:43:02 +0200, Thomas Vandahl wrote:
On 25.08.18 16:14, Gilles wrote:
Probably for those who don't want to use the release plugin :-)
I was mainly following up on the thread about updating CP to AP 21
[1]
But yes, it could be used as an alternative hashing method.
I t
On 25.08.18 16:14, Gilles wrote:
>>> Probably for those who don't want to use the release plugin :-)
>>
>> I was mainly following up on the thread about updating CP to AP 21 [1]
>>
>> But yes, it could be used as an alternative hashing method.
>
> I thought that the release plugin was intended for
On Sat, 25 Aug 2018 19:05:55 +0200, Stefan Bodewig wrote:
On 2018-08-25, Gilles wrote:
On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:
On 25 August 2018 at 09:48, Stefan Bodewig
wrote:
On 2018-08-25, Gary Gregory wrote:
Is what you are referring to for a different purpose?
Probably for
On 2018-08-25, Gilles wrote:
> On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:
>> On 25 August 2018 at 09:48, Stefan Bodewig
>> wrote:
>>> On 2018-08-25, Gary Gregory wrote:
Is what you are referring to for a different purpose?
>>> Probably for those who don't want to use the release plugi
On Sat, 25 Aug 2018 14:06:44 +0100, sebb wrote:
On 25 August 2018 at 09:48, Stefan Bodewig
wrote:
On 2018-08-25, Gary Gregory wrote:
Our release plugin already creates SHA256 and SHA512 files and
saves those
to Apache's dev/dist for an RC as part of creating an RC, pushing
it to
Nexus and d
On 25 August 2018 at 09:48, Stefan Bodewig wrote:
> On 2018-08-25, Gary Gregory wrote:
>
>> Our release plugin already creates SHA256 and SHA512 files and saves those
>> to Apache's dev/dist for an RC as part of creating an RC, pushing it to
>> Nexus and dist/dev.
Ah, I've not looked at that yet.
On 2018-08-25, Gary Gregory wrote:
> Our release plugin already creates SHA256 and SHA512 files and saves those
> to Apache's dev/dist for an RC as part of creating an RC, pushing it to
> Nexus and dist/dev.
> Is what you are referring to for a different purpose?
Probably for those who don't wan
Our release plugin already creates SHA256 and SHA512 files and saves those
to Apache's dev/dist for an RC as part of creating an RC, pushing it to
Nexus and dist/dev.
Is what you are referring to for a different purpose?
Gary
On Fri, Aug 24, 2018 at 6:03 PM sebb wrote:
> As noted in another th
22 matches
Mail list logo
