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
