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?
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.