2

I'm trying to determine if there is a way to use the maven-release-plugin with my SCM setup. The way that the SCM is setup is that there are 2 long living branches - a development branch (DEV) and an Integration branch (INT). I'm using JazzRTC as an SCM, but I don't think that the SCM choice is necessarily an important factor. There is already a Maven SCM Jazz Provider.

Typical workflow is to start a version in the dev branch (ex: 1.0.0-SNAPSHOT) and commit all changes to the DEV branch. Once the branch is ready for release, all changes are merged into the INT branch, the pom's versions are changed (ex: 1.0.0) and a package is deployed from the INT branch.

At this point, the pom versions on the dev branch are updated (1.0.1-SNAPSHOT) and further development continues for bug fixes, updates, etc.

Given the default workflow of the release-plugin, I'm trying to figure out if it is even usable in my context. At the moment, the release plugin cycles through the following phases:

  • Check that there are no uncommitted changes in the sources
  • Check that there are no SNAPSHOT dependencies
  • Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  • Transform the SCM information in the POM to include the final destination of the tag
  • Run the project tests against the modified POMs to confirm everything is in working order
  • Commit the modified POMs
  • Tag the code in the SCM with a version name (this will be prompted for)
  • Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  • Commit the modified POMs

My issue with these steps is that I do not want/need the POM changed from x-SNAPSHOT to a fixed version (ex: 1.0.0) and committed in the DEV branch, but rather in the INT branch.

Is there a way to use/configure the release-plugin given 2 separate branches like this?

Eric B.
  • 23,425
  • 50
  • 169
  • 316
  • @fge - Thanks, but changing underlying build/release technologies is not an option. – Eric B. Apr 13 '15 at 19:57
  • We basically do the same with one big difference: We create a new release branch for every new minor release (1.0, 1.1, 2.0, 2.1, 2.2, ...) rather than using one for all, like your INT. I wonder how you apply bug fixes and release fix versions for previous releases. Let's say you deployed/delivered v1.0.0 a few months ago.Latest version is v3.0.0. Now there is a request for a serious bug's fix in v1.0.0 which becomes v1.0.1 then (customer doesn't need, want or can't wait for 3.1.0). Where do you apply the changes? From where do you prepare this fix version? – Gerold Broser Apr 13 '15 at 23:02
  • @GeroldBroser - Actually, it's one set of Dev/Int branches for each minor release. So there is an Int/Dev for 1.0.x, Int/Dev for 1.1.x, Int/Dev for 1.2.x, etc. In a way, it makes things a little easier when prep'ing for a release, but complicates things like using the release plugin. :) For instance, on a given release, the integrator can cherry-pick which change sets he wants to include in the Int branch for a specific release and not require including all change sets that are in the dev branch. – Eric B. Apr 14 '15 at 15:16
  • @GeroldBroser The idea for the multiple dev branches is 1) to match the Int branches, and 2) to be able to run multiple dev cycles in parallel (ie: work on 1.0.x, 1.1.x, 2.0.x and 3.0.x) at the same time. Otherwise all the commits would be stepping on each other. – Eric B. Apr 14 '15 at 16:14
  • Nice trick! Telling there are (just) two branches though there actually are _two for each release._ ;-P _"one set of Dev/Int branches for each minor release"?_ Really? What's the advantage of and/or the idea behind branching the dev branch to another dev branch? To enable your integrator to work w/o interference? We have just one dev branch and create a rel branch from it when the time for a release has come. Then we change to the next snapshot version on the dev branch and change to the release version on the rel branch. Thus, no need for switching versions forth and back on the dev branch. – Gerold Broser Apr 14 '15 at 16:30
  • [Oops, revised my previous comment and re-added it after your reply.] What do you exactly mean by _"match the Int branches"?_ Doesn't the 'x's mean that these are (bug) fix releases? Are there so many that you have full dev cycles there? They rarely occur here and are applied to the rel branch directly and cherry-picked to the dev branches once they are finished. But maybe this "stepping on other's feet" doesn't occur here because we separated our app into 15 modules with 15 repositories behind. – Gerold Broser Apr 14 '15 at 16:46
  • @GeroldBroser Basically the goal is to always have the two branches (Dev & Int) follow each other. There are often 3-4 versions being developed in parallel, and once a version is released via the Int branch (to QA) there might be 4 or 5 cycles of bug fixes/patches that are released to rectify issues caught during testing before even put into prod. And even once in prod, there may be 3 or 4 patches that must be released. So it is easier to always have both branches run in parallel, although technically not really required. – Eric B. Apr 15 '15 at 01:21
  • Have you ever figured out a solution @EricB.? – timbru31 Dec 14 '17 at 17:36
  • @timbru31 I moved on from that project a couple of years ago and my recollection is a little hazy, but in the end, I believe I just ended up using the release plugin in the Int branch, and nothing in the Dev branch. The merges always went from dev -> int and poms were only change automatically in the int. If I remember right, new versions would branch off the Int branch (inheriting the latest poms) so that all future changes to version in dev (assinging a Snapshot) would be in the dev branch and then cascade to Int upon the merge. – Eric B. Dec 14 '17 at 17:49

0 Answers0