continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <>
Subject Re: Release Management for Maven/Continuum
Date Wed, 23 Aug 2006 14:17:22 GMT
Some thoughts.

I could see the need to go back into the build history and creating a 
release off of an older build to be quite likely too.

Also, should the locking of the project be at the Continuum/filesystem 
side, or on the SCM side?  If scm side, we should add 
supportsLock()/lock()/unlock() support to maven-scm soon.

As for multi-module, make it context sensitive as you describe. 
maven/trunk/components/ = full maven release process (multi-module)
maven/trunk/wagon/wagon-providers/ = wagon providers only release 
maven/trunk/jxr/ = jxr release (single module)

Might prove useful on a multi-module to display/show the affected 
projects/scm's on the prepare release screen as a confirmation to the 
user of the release process to use.

Also, about security, we definitely need to setup a ROLE for this 

- Joakim Erdfelt

Brett Porter wrote:
> Finally getting around to replying :)
> I spoke to Edwin on IRC and he's proposed the following steps:
> 1) go to the project group...
> 2) then click on the release project icon ( a new icon )
> 3) then a page will prompt for the release version and the next dev 
> version...
> 4) after filling the required parameters, click the prepare for 
> release button...
> 5) the page after the procedure is either a progress or an 
> auto-refreshing page, i'm still open )
> 6) when the release prepare is a success, then a button for the 
> perform release is shown
> 7) otherwise, some kind of a build failure report will be shown
> 8) and repeat 6/7 during perform release
> So this part is pretty straightforward. For 3) the webwork modeldriven 
> action can be used against the modello model to easily produce a form 
> page. For 5) the WW showcase has a "run in background, show page and 
> refresh" example that could be used, though I consider that a nice to 
> have.
> There seems to be a pretty good base with the current model. I think 
> the tasks that are needed in the release plugin:
> - add any missing elements to the model
> - change the release mojos to marshal arguments to this instead of the 
> current configuration classes and pass that into the release process
> - need to retain the ability to prompt for those not specified as 
> happens now, so the prepare(Release) method will be new. Continuum 
> will set the mojo into non-interactive mode to ensure this doesn't 
> happen.
> And in continuum its wiring up the steps as above. Edwin was going to 
> make adjustments to the white site to be able to visualise this before 
> diving in.
> The tricky things that might need more discussion:
> - how are multi-module projects handled in Continuum? I think for this 
> incarnation we go with the simple solution which is to just trigger it 
> on the project on its merits (so if its the parent, the whole lot is 
> released)
> - how is the project built? Is it queued into Continuum, or are the 
> same tools used to run a separate build in the background?
> - what files are modified? the current checkout in Continuum, or a 
> clean one? If it is the current one, builds need to be locked out 
> while the release process is in progress.
> I think the short term solution is to go with a clean checkout and 
> doing it all in the background, separate from the continuum build 
> queue. This seems the easiest.
> In the long term, has Continuum becomes more feature rich, I would 
> rather see it is a queued build with certain settings enabled (clean 
> checkout, clean repository) so that other features such as monitoring 
> the scheduling could be reused.
> Thoughts?
> How could the work be partitioned up so that both interested people 
> can work on it effectively?
> Cheers,
> - Brett
> On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
>> Continuum Dev,
>>    I am currently working on a mechanism to have Maven's release 
>> plugin to
>> actuall use Continuum to perform the release process in a "Release
>> Management" type of usage.  Jason Van Zyl and I have talked about 
>> this for
>> the last few days to flesh out the approach and here are the two Jira 
>> that
>> should get you up to speed with what I am doing:
>> Jason has given me some good tips and such and I plan on starting this
>> tomorrow sometime.  If any of you have any concerns, complaints or
>> suggestions, please let me know.
>> Take care,
>> Jeremy

View raw message