Last week we ran into a problem with our Octopus deployment: After a bug fix on the release branch we noticed that the new build had not automatically been deployed to our staging system. The reason for this was quickly found. We expected that the NuGet Package version was incremented by one such as Package.1.2.3-beta0002, but it was still Package.1.2.3-beta0001. Therefore, Octopus took no action since this particular version was already deployed.
After all it turned out that the 4-digit number suffix won’t increment automatically no matter how many commits you have done on the release branch. The same behavior is also true for hotfix branches.
However on the develop branch the 4-digit number suffix in incremented on each commit as I would expect it to be since a commit has a side effect and build artifacts aren’t obviously the same as before.
So why are there different behaviors on the branches mentioned above? The very short and personal answer is: I don’t know! But at least I can tell you how you can manipulate the number suffix: The trick is to use tags. Let me explain this with an example using GitFlow .
Here are some comments:
Initial commit on the master branch and creation of the develop branch.
The unstable number suffix starts with 0000 since no commit was made on the development branch. So far so good…
Steps 3, 9, 17
Branching of release and hotfix branches. The number suffix starts with 0001. Here I would expect it to be 0000 since no commit was yet made to this branches (see step 0).
Steps 6, 8, 14, 19
Creation of a new tags. This leads to the desired suffixes.
Please note: Without the tag the suffix would still be like the previous one!
Interestingly the suffix is incremented automatically but only once!
Steps 10, 11, 12, 16, 17
After merging the release branch into develop I would expect to reset the suffix to 0000 since no ‘real’ commit was yet made to the develop branch. Therefore, all suffixes should be interpreted as suffix value minus 1. But that’s my personal interpretation… The important thing is that the suffix in incremented on every commit which is indeed the case.
In order to extract the version numbers, I created a very simple Git repo with a text file and the latest stable version of GitVersion.exe . In the text file, I incremented an arbitrary number so that I had something to commit. The version I took, was the one tagged with “NuGetVersion”:
I didn’t test the whole workflow with Octopack  but I have noticed before that the beta build number suffix wasn’t incremented either.
In summary, I’m still a big fan of the GitFlow model and tools like GitVersion.exe and Octopack even though there are some weird cases with automatic versioning. If you ran into similar problems, I hope that this post is somehow useful to you. If you even know a good reason for the versioning mentioned above behavior, please write it in the comments below!
– Gitflow Workflow by Atlassian
– Introducing Gitflow by Datasift
– A successful Git branching model by Vincent Driessen
– Gitflow Cheat Sheet by Daniel Kummer
– Introduction page by ParticularLabs
– GitHub repository
– Documentation by Octopus Deploy
– GitHub repository