commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [build-plugin] Re-engineering/release streamlining
Date Mon, 13 Nov 2017 02:48:08 GMT

> On Nov 12, 2017, at 5:25 AM, sebb <sebbaz@gmail.com> wrote:
> 
> On 12 November 2017 at 04:26, Matt Benson <mbenson@apache.org> wrote:
>> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <chtompki@gmail.com> wrote:
>> 
>> 
>> 
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <garydgregory@gmail.com> wrote:
>>> 
>>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <chtompki@gmail.com>
wrote:
>>>> 
>>>> Hello all,
>>>> 
>>>> I was wondering if we might think about a 2.X line in the [build-plugin]
>>>> to better facilitate our release mechanics so that we don’t have to jump
>>>> through all of these hoops that we do when building a release candidate?
>>>> 
>>>> Steps:
>>>> 1. Move the commons-build-plugin to git.
>>>> 
>>> 
>>> +1
>>> 
>>> 
>>>> 2. Fully rewrite it so that it retains its site/github templating, but
>>>> adds functionality to perform our releases in git (maybe withholding svn
>> on
>>>> purpose to incentivize moving repositories to git).
>>>> 
>>>> Thoughts?
>>>> 
>>> 
>>> I agree, it's a pain. I wonder if we should step back first and see if we
>>> can simplify our release requirements. For example, I find it a huge pain
>>> that we have to release to both Nexus and the dist folder. I wonder if we
>>> could get away with putting ALL we need in Nexus. After it's all on Apache
>>> infra...
>>> 
>> 
>> 
>> I'm going to go out on a limb and say this won't fly.
> 
> It cannot fly.
> 
> Apache releases must use dist, and Maven releases must use Nexus.

I’m indifferent with storage locations, but I figure we might as well get as much of the
process into the [build-plugin] so that it’s scripted as Matt says. So I’ll start down
that path unless there is considerable dissent. If I don’t hear anything by mid week, I’ll
try to start moving the [build-plugin] into git.

Any thoughts on whether or not we try to go 2.X with it, particularly because I would be upversioning
a lot of dependencies to write the scripting in java? Maybe it’s not necessary though.

-Rob

> 
>> BUT there is no
>> reason we can't script all this kind of stuff to our hearts' content.
> 
> +1
> 
>> Matt
>> 
>> 
>> Sure. What’s the process for changing the requirements? Proposal...vote? I
>> can try to work from the existent requirements, trim some fat, and bring it
>> back for edits.
>> 
>> -Rob
>> 
>>> Gary
>>> 
>>> 
>>>> 
>>>> Cheers,
>>>> -Rob
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> 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