You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rob Tompkins <ch...@gmail.com> on 2017/11/12 03:19:53 UTC
[build-plugin] Re-engineering/release streamlining
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.
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?
Cheers,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [build-plugin] Re-engineering/release streamlining
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 12, 2017, at 5:25 AM, sebb <se...@gmail.com> wrote:
>
> On 12 November 2017 at 04:26, Matt Benson <mb...@apache.org> wrote:
>> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <ch...@gmail.com> wrote:
>>
>>
>>
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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
Re: [build-plugin] Re-engineering/release streamlining
Posted by sebb <se...@gmail.com>.
On 12 November 2017 at 04:26, Matt Benson <mb...@apache.org> wrote:
> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <ch...@gmail.com> wrote:
>
>
>
>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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.
> 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
Re: [build-plugin] Re-engineering/release streamlining
Posted by Chas Honton <ch...@honton.org>.
Take a look at how the maven team votes and publishes
Chas
> On Nov 11, 2017, at 8:26 PM, Matt Benson <mb...@apache.org> wrote:
>
> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <ch...@gmail.com> wrote:
>
>
>
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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. BUT there is no
> reason we can't script all this kind of stuff to our hearts' content.
>
> 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
Re: [build-plugin] Re-engineering/release streamlining
Posted by Matt Benson <mb...@apache.org>.
On Nov 11, 2017 9:32 PM, "Rob Tompkins" <ch...@gmail.com> wrote:
> On Nov 11, 2017, at 10:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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. BUT there is no
reason we can't script all this kind of stuff to our hearts' content.
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
Re: [build-plugin] Re-engineering/release streamlining
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 11, 2017, at 10:24 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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...
>
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
Re: [build-plugin] Re-engineering/release streamlining
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <ch...@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...
Gary
>
> Cheers,
> -Rob
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>