On Sunday, 24 March 2013, Andrei Pozolotin wrote: > Robert, Stephen: > > 1) from my experience "release root / top-to-bottom / monolithic " is a > wrong approach. > please consider instead "start-from-any-module / from-bottom-up / > incremental" approach, as implemented here: > https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki >
You are not getting my plan. The plugin I envision will allow picking a release root from the reactor's set of release roots (suggesting which ones need a release) and then run release on that one. You then iterate until it says all done or you have released what you need No Big Bang from my PoV > > > 2) it would be good to have some wiki page somewhere to flesh out all > assumptions that currently go into release > as well as to list the use cases people really need. here is one of my use > cases: > > https://github.com/barchart/barchart-jenkins-tester-ecosystem/blob/master/readme.md > > Andrei > > -------- Original Message -------- > Subject: Re: Multi-project releases > From: Robert Scholte <[email protected]> <javascript:_e({}, 'cvml', > '[email protected]');> > To: Maven Developers List <[email protected]> <javascript:_e({}, > 'cvml', '[email protected]');> > Date: Sun 24 Mar 2013 09:42:27 AM CDT > > Hi Stephen, > > I've just checked your code. > Most interesting is our difference of the definition "releaseRoot" (or in > my case rootProject, I think we mean the same thing with it). > If I'm correct you base it on the existence of the <scm>-section and if it > has ever been released (assuming a specific scm comment). > MRELEASE-814[1] is probably a good example for which this strategy won't > work. > I try to base it on the parent/module relationship. > > Although this looks close related to MRELEASE-516[2] it is actually a > complete other issue. > The problem I have with MRELEASE-516 is that it's not the "plug-and-play" > behavior you'd like to have, > which means that the developer is responsible for checking out separate > projects in the right structure. > > Robert > > [1] https://jira.codehaus.org/browse/MRELEASE-814 > [2] https://jira.codehaus.org/browse/MRELEASE-516 > > > Op Mon, 11 Mar 2013 12:50:38 +0100 schreef Stephen Connolly > <[email protected]> <javascript:_e({}, 'cvml', > '[email protected]');>: > > Hey one and all, > > So we all know how multiple projects with multiple release roots are a > pain... > > Here's some experiments I've been playing with... > > Not yet brave enough to have it fire up release:prepare release:perform on > each release root, nor fire up versions:set on the downstream projects > with > explicit dependencies, nor lather rinse repeat until there is nothing > needing a release... > > But even the simple report should be useful, and if anyone has suggestions > to help improve its recommendations towards getting confidence that the > automated stuff could work... please give me pull requests. > > If this proves useful, I will probably roll it into the release plugin... > but for now I'll keep it in a holding pattern on github (where it is not > in > a default plugin groupId and hence relocation is less of an issue if I do > happen to make any releases into central) > > $ mvn com.github.stephenc.maven:mpr-maven-plugin:list-roots > > from an aggregator pom should identify all the release roots and whether > they might need a release > > -Stephen > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected]<javascript:_e({}, > 'cvml', '[email protected]');> > For additional commands, e-mail: [email protected]<javascript:_e({}, > 'cvml', '[email protected]');> > > > > -- Sent from my phone
