CODEWITHSUNDEEP
javamavensvnmaven-release-plugin
Daniel Kaplan
Daniel Kaplan

Reputation: 67494

What is the proper workflow to use with the maven-release-plugin?

I only have experience releasing with SVN commands (via tortoiseSVN) but I'd like to use the maven-release-plugin instead. But my experience has been that the maven-release-plugin is very, very picky. I'd like to know how I should be doing releases and branches so I'm not fighting against the plugin. What are the proper maven-release-plugin workflows for these two situations:

  1. Everyone's developing on trunk and we decide to give a version to a customer.

    My guess is you should do a release:prepare release:perform on trunk for this. It will put the version in the tags directory. You give the tag to customers.

  2. We gave a version to a customer but a bug was found. How do I go about fixing the bug in their version and giving them a new version?

    My guess is you should copy the tag into the branches directory using release:prepare release:branch on the tag. Put the branch in a directory named "release-version.x" but give the branch a maven version like "release-version.1" After you modify that branch to fix the bug, you release the branch back into the tag directory using release:prepare release:perform. The branch will now have a maven version of "release-version.2"

    If you need to fix another bug after that, you simply modify the "release-version.x" branch that you already have, and run another release:prepare release:perform on it.

  3. You want to "freeze" development on a branch and potentially give it to a customer, but you're pretty sure bugs will be found in it before you are ready to deploy it to a production server.

    My guess is you can release a .0 and when/if a branch is found branch the .0 to .1-SNAPSHOT, fix it in SNAPSHOT and release the branch to .1.

    But, you may not aesthetically like the idea that the customer first gets a .1 or a .2 release. If you don't like that, you can use the release:branch goal to create the branch first and then release that branch only when you're ready.

This is all a theory. As I said before, the maven-release-plugin is super picky and I don't know if it'll let me do all these steps. Can someone explain the best workflow to use for tagging and branching code in maven?

Upvotes: 2

Views: 1976

Answers (1)

Jepper
Jepper

Reputation: 1111

I'm assuming your maven version numbers are part of the problem. Here's an idea:

In response to 1) When you release, first branch, then release from branch immediately after. It saves you from tidying up the trunk pom if the release plugin fails.

In response to 2) When you branch, and maven increase the trunk version from 1.0.0-SNAPSHOT to 1.0.1-SNAPSHOT, we actually have the problem right there.

If we could increase the minor version instead of the incremental version, we would have

1.0.0-SNAPSHOT in the branch, and 1.1.0-SNAPSHOT in trunk and 1.0.0 in the release / tag.

When you fix a bug, branch from the tag 1.0.0 and set the version to 1.0.1-SNAPSHOT in the new branch. This step, is something like 

mvn release:branch -DbranchName=fixMe -DupdateWorkingCopyVersions=false

from the within tag directory in question.

Fix bug and release from your branch version 1.0.1 using mvn release:prepare and release:perform.

Use the option -DupdateWorkingCopyVersions=false so the tag version isn't updated.

Use the versions:set plugin to set the version in the branch. This may require a shell script to work out the incremental version, or just by hand if you don't do it often.

Upvotes: 1

Related Questions