4

I'm having trouble understanding how to use version numbers. On my team our basic work flow works like this. The development cycle in my team looks like this.

Continuous development is done in our dev environment. Once a month we have a code freeze where the current version of the application is deployed to a separate QA environment where our QA staff tests it for stability and any bugs the developers missed. Once QA is satisfied (this takes 1 to 2 weeks depending on QA's workload), the QA version is deployed to our live production servers.

We're moving from Subversion to Git and I'm trying to design our branching/release strategy to support this. What I'd like to do is this:

Starting point: DEV is running on version 1.0-SNAPSHOT on master
At Code Freeze: Create a new branch release-1.0 from master. Increment the POM on master to 1.1-SNAPSHOT
After QA: Deploy version 1.0 to our nexus server and tag the repository. Merge release-1.0 into master so any bug fixes or change get integrated into future releases.

The problem is that when I merge release-1.0 into master I get a merge conflict on the POM's version. <version>1.1-SNAPSHOT</version> conflicts with <version>1.0</version>. The merge conflict is simple to resolve, but it prevents me from automating this step.

Ideally the release branch can be kept as a maintenance branch with a development version of 1.0.1-SNAPSHOT but I don't want that change to be integrated into the master branch. Otherwise I'm happy just deleting the release branch and relying on the tag to create any hot-fix branches for the 1.0.1 version since that's only for critical production issues that can't wait for the next release cycle.

I'd like to avoid cherry-picking commits from the release branch into master just to eliminate the possibility of missing something and it not getting merged into master.

Is there a way to manage this with the maven-release plugin, or am I doomed to do this manually?

GridDragon
  • 2,857
  • 2
  • 33
  • 41
  • 2
    But wouldn't you _always_ have merge conflicts in other files which would require manual resolution in every merge anyway? – Tim Biegeleisen Dec 15 '16 at 03:19
  • Agreed with @TimBiegeleisen , if you are pushing fixes to the master branch for any bugs, you would still have a merge conflict on that file as well. And if it's a separate release all together, you can do it with a bumped up version as well. – Naman Dec 15 '16 at 04:20
  • There is such a thing as doing a merge and specifying either `--theirs` or `--ours` to unconditionally accept one parent's version of things. But because you probably have other files besides your POM, you would be throwing the baby out with the bathwater by blindly accepting one version of every file over the other. – Tim Biegeleisen Dec 15 '16 at 04:21
  • I tried with custom merge filter drive before: http://stackoverflow.com/q/22909620/6309 – VonC Dec 15 '16 at 05:38

1 Answers1

4

As mentioned by Tim, if your project sources contain the version number, tag name, planned release date of itself(!), you will always run into conflicts because two branches simply have to disagree on this.

This is common in software projects today. This is the Maven Way, but also the Linux way, however I don't think Linus would accept a conflicting patch in kernel release number or codename - they follow a different model than most projects.

The alternative is to keep a special "0-SNAPSHOT" (in Maven terms) version in source code and modify it only when it's released. Then all development branches would agree and I believe this is what you want.

Note that Maven is not designed with this in mind and you will run into issues. For example, how do you explain your QA that final release (1.0) has different SHA1 hash from what they have approved (1.0-rc-5) just because you changed numbers in the source code?

If you throw out version number from the project sources entirely this will no longer be an issue. I have not found this to be the Maven Way I'm afraid. We need better tools.

sevo
  • 4,559
  • 1
  • 15
  • 31