Jeff, Keith: would you be interested in collaborating on a jenkins plugin for this? Andrei.
-------- Original Message -------- Subject: Re: maven-release-plugin : How to better manage cascading releases From: Keith Collison <ke...@vervewireless.com> To: jenkinsci-users@googlegroups.com Date: Tue 26 Feb 2013 09:40:59 PM CST > We've put in place the first half of this by adding these goals to our > maven builds: > > versions:use-releases scm:checkin > > The former will update a pom to use released versions of snapshot > dependencies. The latter commits any resulting changes to the > pom.xml. We also use the "includesList" parameter to limit the > release check to our own libraries. See this page > <http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html> for > info regarding this goal and plugin. > > Some caveats to this approach: > > 1. If the pom.xml uses a property to define the dependency version > (i.e. "<version>${defined.elsewhere}</version>"), the versions plugin > will not update the version. > 2. The versions plugin only scans the module's <dependencies> list. > If you have a parent-pom declaration whose version is set to a > SNAPSHOT, it will not update it. > > I'd have reservations, I think, with the exact workflow you've > described, as it might lead to unintended releases. However, if you > started from the most-dependent module (i.e. the webapp or application > you want to release), and then calculated what upstream dependencies > needed to be released, that would be ideal. Just because I've > released some base library upon which 20 apps depend does not mean I > want to cut a release of those 20 apps. > > > > > > > On Tuesday, February 26, 2013 1:06:16 AM UTC-5, Andrei Pozolotin wrote: > > Hello, there! > > I am curious : "How to better manage cascading releases" > for the following use case and what you think about possible > solution: > > ################################# > > > Releasing core bundles and dependent bundles > > Changing the API of a core bundle for an application requires > a rebuild of everything down the line in order to use the new > feature. For projects with large numbers of modules (platform, > news) this is a very lengthy process of splitting the bundles > into dependency phases, then for each phase, releasing a new > version of each bundle, updating the next phase's bundles with > the newly released versions, and then releasing next phase's > bundles, etc, etc. This can be a multiple hour process with > Jenkins, compounded by the fact that you can only release one > sub-project at a time in a Git repository to avoid push > conflicts causing the build to fail. This process occurs much > more frequently than I would have originally assumed. Right > now I have a bash script that attempts to automate this for > news with a combination of the maven release and version > plugins, but a better generic solution would be very welcome. > > *Proposal: Modify Jenkins maven release plugin with the > following behavior:* > > 1. > > Add a "Cascade release dependent projects" checkbox on > release page > > 2. > > After the release completes, look for jobs that are > explicitly dependent on the pre-release snapshot version > > 3. > > Update these dependent modules with the newly release > version, and trigger a Maven release on them as well > > 4. > > Failing releases should be skipped, and then trigger a > build failure at the very end, with clearly noted messages > as to which sub-tree failed so the user can check the logs > and manually cascade release the subtree > > Step c) would need some cycle detection to support scenarios > where B and C depend on A, but C also depends on B - both A > and B would have to be released before C could be released. > > ################################# > > Thank you, > > Andrei > > -- > You received this message because you are subscribed to the Google > Groups "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
