I'm late to the party here, tonight, but can we clarify what a "multi
project release" is? is it a multi module release? or something more like
continuous release?

As for "needs release" how can this be automatically determined? This seems
fundamentally human to me? Or do you simply mean "dependency on snapshot of
some project, find that project, release it, update dep to point at
arbitrary release" ?

Thanks for the heads upon this thread via IRC, appreciated!

Regards,

Fred.

On Sun, Mar 24, 2013 at 8:32 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> 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 <rfscho...@apache.org> <javascript:_e({}, 'cvml',
> > 'rfscho...@apache.org');>
> > To: Maven Developers List <dev@maven.apache.org> <javascript:_e({},
> > 'cvml', 'dev@maven.apache.org');>
> > 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
> > <stephen.alan.conno...@gmail.com> <javascript:_e({}, 'cvml',
> > 'stephen.alan.conno...@gmail.com');>:
> >
> > 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: dev-unsubscr...@maven.apache.org<javascript:_e({},
> 'cvml', 'dev-unsubscr...@maven.apache.org');>
> > For additional commands, e-mail: dev-h...@maven.apache.org<javascript:_e({},
> 'cvml', 'dev-h...@maven.apache.org');>
> >
> >
> >
> >
>
>
>
> --
> Sent from my phone
>

Reply via email to