Stephen

    OK! We won't! :-) Thank you,

    Andrei 

-------- Original Message --------
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Stephen Connolly <stephen.alan.conno...@gmail.com>
To: jenkinsci-users@googlegroups.com <jenkinsci-users@googlegroups.com>
Date: Thu 28 Feb 2013 10:54:54 AM CST
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
> Please don't host your own maven repositories on an SCM
>
>
> On 28 February 2013 16:50, Jeff <predato...@gmail.com
> <mailto:predato...@gmail.com>> wrote:
>
>     Does github have a maven repository?
>
>
>     On Thu, Feb 28, 2013 at 7:17 AM, Andrei Pozolotin
>     <andrei.pozolo...@gmail.com <mailto:andrei.pozolo...@gmail.com>>
>     wrote:
>
>         *Jeff, Keith, Jeremy:*
>
>         so it seems we have few different use cases in mind between us.
>
>         it would probably help if we create 2-3 mock repositories on
>         github
>         to emulate our most interesting use cases.
>
>         what do you think?
>
>         Andrei.
>
>
>         On Tuesday, February 26, 2013 12:06:16 AM UTC-6, 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
>         <mailto:jenkinsci-users%2bunsubscr...@googlegroups.com>.
>         For more options, visit https://groups.google.com/groups/opt_out.
>          
>          
>
>
>
>
>     -- 
>     Jeff Vincent
>
>     See my LinkedIn profile at:
>     http://www.linkedin.com/in/rjeffreyvincent
>     I ♥ DropBox <http://db.tt/9O6LfBX> !! 
>     -- 
>     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
>     <mailto:jenkinsci-users%2bunsubscr...@googlegroups.com>.
>     For more options, visit https://groups.google.com/groups/opt_out.
>      
>      
>
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/4OZsB9LV6nE/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, 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.


Reply via email to