Hi, We currently have the following process for our releases:
Walk the DAG of our modules in a breadth-first traversal [1] and for each module being released: 1) Create a branch in Subversion. 2) Check out the branch 3) Update the POMs so that no SNAPSHOT dependencies are stil in the POMs and commit these updates in the branch. 4) mvn release:prepare -D... 5) mvn release:perform 6) Update the POMs to reference the new SNAPSHOT dependency versions and commit these updates in the branch. 7) Merge the updated POMs back into main trunk. We have some Python scripts to do steps 1-3 and 6,7. Unfortunately step 4 doesn't seem to be possible to fully script due to prompting for release numbers and next development numbers. We could do more work with the reading and writing of child stdin / stdout, but I think it would be preferable for the release plugin to support being invoked in an enabling manner which assumes that we know what we are doing and just to use the defaults. I also noticed that the maven-release-plugin has had some changes in the last few months, with a new release:branch goal. And from a brief look at the plugin code, the logic is in place to do steps 3 and 6 within the plugin, but it doesn't appear to be exposed. I would like to be able to move to an all Maven solution. 1. Does this look possible, given the process that we have? And is it possible using the current release plugin, if invoked correctly, or would it require changes to expose the desired functionality? Please provide any examples of how you think this should work. 2. If I'm correct and the prepare step can't be automated, does anyone think this is a reasonable idea? If so, I'll raise a JIRA issue and look at whether I can provide a patch. Regards, James [1] http://en.wikipedia.org/wiki/Breadth-first_search --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
