I’m having some issues with GitVersion.
I have added next in my package.xml file.
Version="$(GitVersion)"
When I compile my code (in VS) I get something like:
0.1.0-alpha.2.3+44df7d36.release0-2-0.TapPackage
The 0.1.0 is probably from the .gitversion file. But why is it ‘alpha’ when I’m working on a release branch? The release branch is added at the end but I would rather expect it to be ‘rc’ instead of alpha? Or am I wrong?
It’s based on https://doc.opentap.io/Developer%20Guide/Plugin%20Packaging%20and%20Versioning/#versioning
When I’m on the develop branch I get something similar:
0.1.0-alpha.2.3+44df7d36.develop
Here I would expect to see beta instead of alpha?
Only when I’m on the main branch, the version is beta:
0.1.0-beta.1.1+48d35a22
As I would expect (although the documentation doesn’t mention a ‘main’ branch (only ‘dev’, ‘develop’, ‘master’ and ‘integration’) but I would assume the documentation is not up to date?).
Also, why do we need a .gitversion file with the version number? Is not the idea that version numbering is based on tagging?
I have non experience with GitVersion so sorry for my maybe silly questions … 
if you want to call your branch release0-2-0, you probably need to change the regex pattern for release branches. By default I think it is set to:
#release branch = release[0-9x]*
so this should probably be something like
release branch = release[0-9\-]*
?
Not 100% though.
The branch is not called release0-2-0 but release0.2.0. GitVersion replaces the . (dot) with - (dash) I guess.
But your reply helped me. I renamed my branch to release and that seems to work. It now becomes:
0.1.0-rc.3+44df7d36
I work with Tower Git and the Release branches are by default set to release/xxx (where xxx is the name of the release, typically I set this to the the version number like 1.0.0). According to me GitVersion should not have a problem with this but I’m not the expert.
I tried to change the Regex to
release\/[0-9.x]*
but not yet a success. Although on regex101.com it seems to be working.
This may be a stupid question, but did you make a commit after making changes to your .gitversion file? If you didn’t make a commit, OpenTAP will use the revision of your .gitversion file from the current commit
2 Likes
You just made my day. I didn’t understand it why it didn’t wanted to work. But had no idea that I needed to commit before it to work as expected. 
2 Likes
Is it correct that you still need to set the version number in .gitversion file?
version = 0.2.0
Adding a tag with 0.2.0 will not do the job if version = 0.1.0 is set in .gitversion?
I thought that was the idea of GitVersion?
If you set a tag to v0.2.0 but version = 0.1.0 is set in .gitversion, the version will look like:
0.1.0
and not 0.2.0.
There is no ‘rc’, ‘alpha’ or ‘beta’ in the version number anymore due to the tag (which is as expected) but it can become confusing.
I thought the idea of the tags in GitVersion was that these tags will define this version number? If you tag it with 0.2.0 it will become version 0.2.0. And if you add some commits it would become 0.2.0+4 for instance (or something in that trend).
1 Like
I’ve been under the impression that the packager only checks for the existence of an annotated tag, but doesn’t actually use the tag value.
You are asking a good question, and David is correct. We only check for the existence of an annotated tag, not the tag value.
The problem with relying only on git tags is when alphas and betas enter the equation. Semantically, version 2.0.0-beta.1 preceedes release version 2.0.0. If we tried to calculate the next beta version after tagging 2.0.0, we would need to bump it to reflect that the new beta may have a different set of features from the prior release.
But OpenTAP assumes semantic versioning, so the beta version is dependent on the nature of the code changes. If a new API has been added, the minor must be bumped. If a breaking change was made, the major must be bumped. If the plugin was renamed, it is perfectly legal to reset the version to 1.0.0.
Only the developer knows what the next version will be.
I personally maintain many different plugins, and I don’t have experience with other implementations of git versioning, so I am interested in hearing different perspectives on more automated versioning.
I base myself on this explanation.
The way I understand it.
If you tag with 1.0.0, the version will become 1.0.0.
If you go to the Develop branch the version will become 1.1.0-alpha.1 after a first commit. After 3 more commits it will become 1.1.0-alpha.4.
GitVersion assumes that what you develop in this branch is backwards compatible (that’s why the minor changes). It also assumes it’s the least stable version so alpha.
When you are ready to release, you start a release branch. The version will automatically be updated to 1.1.0-beta.1+0.
Beta because GitVersion assumes this version is more stable. At each commit the last number will increase (1.1.0-beta.1+1 → 1.1.0-beta.1+2 → …).
When you are ready to make a first beta release (a release candidate), you add a tag like 1.1.0-beta.1.
The version will now become 1.1.0-beta.1. If you add new commits after adding this tag, the version will become 1.1.0-beta.2+0 → 1.1.0-beta.2+1 → 1.1.0-beta.2+2 → … Notice beta.1 increase to beta.2 due to the tag 1.1.0-beta.1. GitVersion knows it need to increase this number.
When you are ready to release, you tag with 1.1.0-beta.2 (in this example). You merge in the main branche (and also the develop branche) and you tag the main branche with 1.1.0 and now you have your release 1.1.0.
If you now go back to the develop branch and you start committing, the version will become 1.2.0-alpha.1. GitVersion knows it needs to increase the minor due to the last tag 1.1.0.
If you need to update the major version, you could create a release branch called release/2.0 and the version will automatically jump to 2.0.0-beta.1+0 (beta because we are in a release branch).
Above is how I understood GitVersion is working. But again, I’m far from being an expert and every way of working will have its advantages and disadvantages.
Thanks for the explanation. For most projects it is probably acceptable to just bump minor when you branch off from a tag. I prefer more fine grained control for the plugins I maintain, but it would be cool if we could fall back to an automatic versioning scheme if there is no .gitversion file.
1 Like
