[build-plugin] Re-engineering/release streamlining

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[build-plugin] Re-engineering/release streamlining

Rob Tompkins
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

garydgregory
On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

Rob Tompkins


> On Nov 11, 2017, at 10:24 PM, Gary Gregory <[hidden email]> wrote:
>
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

Matt Benson-3
On Nov 11, 2017 9:32 PM, "Rob Tompkins" <[hidden email]> wrote:



> On Nov 11, 2017, at 10:24 PM, Gary Gregory <[hidden email]> wrote:
>
>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

Charles Honton
Take a look at how the maven team votes and publishes

Chas

> On Nov 11, 2017, at 8:26 PM, Matt Benson <[hidden email]> wrote:
>
> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <[hidden email]> wrote:
>
>
>
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <[hidden email]> wrote:
>>>
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

sebb-2-2
In reply to this post by Matt Benson-3
On 12 November 2017 at 04:26, Matt Benson <[hidden email]> wrote:

> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <[hidden email]> wrote:
>
>
>
>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <[hidden email]> wrote:
>>
>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [build-plugin] Re-engineering/release streamlining

Rob Tompkins

> On Nov 12, 2017, at 5:25 AM, sebb <[hidden email]> wrote:
>
> On 12 November 2017 at 04:26, Matt Benson <[hidden email]> wrote:
>> On Nov 11, 2017 9:32 PM, "Rob Tompkins" <[hidden email]> wrote:
>>
>>
>>
>>> On Nov 11, 2017, at 10:24 PM, Gary Gregory <[hidden email]> wrote:
>>>
>>>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]