Post 1.0 release process

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

Post 1.0 release process

Emmanuel Venisse-2
Hi,

I describe there (http://docs.codehaus.org/display/SCM/Maven-SCM+Release+Process) the release process and scm structure I'd want to use after the release of 1.0.

Emmanuel

Reply | Threaded
Open this post in threaded view
|

Re: Post 1.0 release process

Jason van Zyl

On 27 Mar 07, at 12:30 PM 27 Mar 07, Emmanuel Venisse wrote:

> Hi,
>
> I describe there (http://docs.codehaus.org/display/SCM/Maven-SCM 
> +Release+Process) the release process and scm structure I'd want to  
> use after the release of 1.0.
>

We should do something similar across the board whatever we decide to  
do, but you realize that refactoring would be a severe pain in the  
ass. I agree providers in any form should be amenable to patching and  
releasing but is this the best way to go? It also adds some overhead  
in getting testing working. Can we not release from one structure,  
are we just limited by some deficiencies in the release plugin?

Jason.

> Emmanuel
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Post 1.0 release process

brettporter
Administrator

On 28/03/2007, at 7:51 AM, Jason van Zyl wrote:

>
> On 27 Mar 07, at 12:30 PM 27 Mar 07, Emmanuel Venisse wrote:
>
>> Hi,
>>
>> I describe there (http://docs.codehaus.org/display/SCM/Maven-SCM 
>> +Release+Process) the release process and scm structure I'd want  
>> to use after the release of 1.0.

This is missing the tck module, and the plugin. Also, if we do this,  
the providers should have their own JIRA project.

>>
>
> We should do something similar across the board whatever we decide  
> to do, but you realize that refactoring would be a severe pain in  
> the ass. I agree providers in any form should be amenable to  
> patching and releasing but is this the best way to go?

Yeah, I'm 50/50 on this really. I see the benefit, but I'd rather  
wait until we have a need to release a provider on a base API before  
splitting it off. In addition, the benefit of this is completely lost  
if the providers are tightly coupled to the API - so we might want a  
couple of releases to ensure that's not the case.

> It also adds some overhead in getting testing working.

I don't think this should add any testing overhead if it is done  
right...

> Can we not release from one structure, are we just limited by some  
> deficiencies in the release plugin?

We can release from a single structure, just like the plugins do now.  
Whether that's the right thing to do is also debatable.

I'd hold off on this until we get 1.0's out across the board and then  
hash it out in relation to everything that does the same thing -  
plugins, doxia, scm, wagon... even surefire providers.

- Brett
Reply | Threaded
Open this post in threaded view
|

Re: Post 1.0 release process

Emmanuel Venisse-2


Brett Porter a écrit :

>
> On 28/03/2007, at 7:51 AM, Jason van Zyl wrote:
>
>>
>> On 27 Mar 07, at 12:30 PM 27 Mar 07, Emmanuel Venisse wrote:
>>
>>> Hi,
>>>
>>> I describe there
>>> (http://docs.codehaus.org/display/SCM/Maven-SCM+Release+Process) the
>>> release process and scm structure I'd want to use after the release
>>> of 1.0.
>
> This is missing the tck module, and the plugin. Also, if we do this, the
> providers should have their own JIRA project.

I didn't add all but I thought the same thing for tck, plugin and other providers with trunk/tags/branches

>
>>>
>>
>> We should do something similar across the board whatever we decide to
>> do, but you realize that refactoring would be a severe pain in the
>> ass. I agree providers in any form should be amenable to patching and
>> releasing but is this the best way to go?
>
> Yeah, I'm 50/50 on this really. I see the benefit, but I'd rather wait
> until we have a need to release a provider on a base API before
> splitting it off. In addition, the benefit of this is completely lost if
> the providers are tightly coupled to the API - so we might want a couple
> of releases to ensure that's not the case.
>
>> It also adds some overhead in getting testing working.
>
> I don't think this should add any testing overhead if it is done right...
>
>> Can we not release from one structure, are we just limited by some
>> deficiencies in the release plugin?
>
> We can release from a single structure, just like the plugins do now.
> Whether that's the right thing to do is also debatable.

oh yes, we can do it. I thought to separated trunk without enough coffee in my body ;)
so I'm ok to keep the actual trunk structure.

>
> I'd hold off on this until we get 1.0's out across the board and then
> hash it out in relation to everything that does the same thing -
> plugins, doxia, scm, wagon... even surefire providers.
>
> - Brett
>
>
>