how and when to give version numbers to releases

[tchick]

Hi all,

I really like the jgitflow plugin for creating feature branches. What I do not understand is, how release numbers should be assigned to release and hotfix branches. I used the maven-release-plugin for the last years. Here are some of the things, that irritate me:

1) After starting a release, all changes to this release are to be commited to to the release branch, and all stuff for the next release should go to the develop branch, right? Therefore I think, starting a release should also update the version number in the develop branch to the next SNAPSHOT. Why is this happening when finishing the release? In the mean time, I have a SNAPSHOT version AND the corresponding normal version in two different branches at the same time.

2) Why do release and hotfix branches have non-SNAPSHOT release numbers? Every builds from these branches will have the same version number, regardless of when they are built and of what sources they are build of.

3) Till now I always build releases for which I give a number when building them. They are given to QA, and if not OK, I fix it and then build the next release with the next number. When OK, exactly this release/build goes to production. I think, this is not possible with the jgitflow-plugin, correct? Or did I miss something?

Thanks for bringing light to me,
  tchick.

[Jonathan Doklovic]

RE #1 - this is actually the most voted on issue and we're actively working on it. You can expect develop versions to be ticked on release start with the next milestone release

RE #2 - release and hotfix branches should have snapshot versions until you do a release/hotfix-finish. if this is not the case, please log an issue and include the version you're using and attach your .git/jgitflow.log file

RE #3 - although the number in the branch name is pretty much set when you start a release, the versions in the poms are not. You can use the versions maven plugin (or other plugins) to easily tick the versions in your poms manually. when you run release-finish, it will pick up the new versions from the poms and do the right thing.

[tchick]

Thanks Jonathan for your comprehensive answer.

#1 - Good to hear, that this will be available in the next version. I tried to manually update the version in the develop pom, but unfortunately this will lead to a merge conflict when doing release finish. So I suppose I will do a "mvn jgitflow:release-start jgitflow:release-finish" and tell everybody not to commit to the develop branch in the meantime. (BTW, this is one of the reasons for which I would like to stop using the maven-release-plugin.)

#2 Yes you are right. Sorry for this. So I can build several SNAPSHOTS from this branch. Or maybe better use jgitflow:buildNumber and build RC-versions.

#3 OK - so I have to set the versions and then build release artefacts manually till it's stable.

I think, what irritated me is the different understanding of release branches. gitflow use release branches only temporarily to "move the version from develop to master", while I always thought of them as "the source of releases with the same minor version", which live as long as the minor version is productive anywhere.

At the moment we have a branch for every deployed version, e.g. 5.1 and 5.2, of which we make releases 5.1.x and 5.2.x, while developing 5.3 on branch develop. (One could say have actually TWO masters.) With gitflow we would have all 5.1.x and 5.2.x versions only as tags on the master branch. To fix a bug in 5.1 and 5.2., we would create 2 hotfix-branches for this, correct? But then the tags on master would look like this: 5.1.2, 5.1.3, 5.2.0, 5.2.1, 5.1.4, 5.2.2. Irritating at first, but in chronological follow.

But: we cannot merge between the two hotfix branches, do we? Because they do not exist at the same time.

[Jonathan Doklovic]

I believe what you want is support branches: http://www.syntevo.com/smartgithg/documentation/5/show?page=git-flow#flow.support

We plan to add support for support branches, however, it will be "limited", meaning the plugin will be able to create them for you, but it's nearly impossible to automate the hotifx/release/merge from a support branch since there's no telling on any given day where it should be merged to. Meaning sometimes you merge into master and your support branch, and sometimes you add in develop.

Hope that helps.

- JD