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
> 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
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.
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
As noted in another thread, I don't think the recent change to the
Apache parent pom is of any use to Commons.
However it does provide an example of how to use the checksum plugin.
This has been used to create a sample profile that could be added to CP.
See COMMONSSITE-121
Or for local
23 matches
Mail list logo
