# GitVersion on GitHub **URL:** \ **Category:** General\ **Created:** [December 6, 2023, 3:54pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317 "2023-12-06T15:54:42Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![tomderyck](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/tomderyck/32/788_2.png) [@tomderyck](https://forum.opentap.io/u/tomderyck)\ **Post date:** [December 6, 2023, 3:54pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/1 "2023-12-06T15:54:42Z")
I’m having some issues with GitVersion. I have added next in my package.xml file. ```csharp Version="$(GitVersion)" ``` When I compile my code (in VS) I get something like: ```csharp 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](https://doc.opentap.io/Developer%20Guide/Plugin%20Packaging%20and%20Versioning/#versioning) When I’m on the develop branch I get something similar: ```csharp 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: ```csharp 0.1.0-beta.1.1+48d35a22 ``` As I would expect (although the [documentation](https://doc.opentap.io/Developer%20Guide/Plugin%20Packaging%20and%20Versioning/#versioning) 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 … 😊 ---
**Author:** ![rolf\_madsen](https://avatars.discourse-cdn.com/v4/letter/r/43a26b/32.png) [@rolf\_madsen](https://forum.opentap.io/u/rolf_madsen)\ **Post date:** [December 6, 2023, 4:13pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/2 "2023-12-06T16:13:25Z")
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: ```csharp #release branch = release[0-9x]* ``` so this should probably be something like ```csharp release branch = release[0-9\-]* ``` ? Not 100% though. ---
**Author:** ![tomderyck](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/tomderyck/32/788_2.png) [@tomderyck](https://forum.opentap.io/u/tomderyck)\ **Post date:** [December 7, 2023, 8:59am UTC](https://forum.opentap.io/t/gitversion-on-github/1317/3 "2023-12-07T08:59:22Z")
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: ```csharp 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 ```csharp release\/[0-9.x]* ``` but not yet a success. Although on [regex101.com](https://regex101.com/) it seems to be working. ![Screenshot_3](https://us1.discourse-cdn.com/flex020/uploads/opentap/original/1X/e676b73293022e6175d36a6aa803deeeb9edec91.png) ---
**Author:** ![alexander.larsen](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@alexander.larsen](https://forum.opentap.io/u/alexander.larsen)\ **Post date:** [December 7, 2023, 2:43pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/4 "2023-12-07T14:43:52Z")
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 ---
**Author:** ![tomderyck](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/tomderyck/32/788_2.png) [@tomderyck](https://forum.opentap.io/u/tomderyck)\ **Post date:** [December 7, 2023, 3:05pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/5 "2023-12-07T15:05:32Z")
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. 😔 ---
**Author:** ![tomderyck](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/tomderyck/32/788_2.png) [@tomderyck](https://forum.opentap.io/u/tomderyck)\ **Post date:** [December 7, 2023, 4:24pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/6 "2023-12-07T16:24:30Z")
Is it correct that you still need to set the version number in .gitversion file? ```csharp 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: ```csharp 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). ---
**Author:** ![david-wsd](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/david-wsd/32/204_2.png) [@david-wsd](https://forum.opentap.io/u/david-wsd)\ **Post date:** [December 7, 2023, 5:36pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/7 "2023-12-07T17:36:02Z")
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. ---
**Author:** ![alexander.larsen](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@alexander.larsen](https://forum.opentap.io/u/alexander.larsen)\ **Post date:** [December 8, 2023, 10:22am UTC](https://forum.opentap.io/t/gitversion-on-github/1317/8 "2023-12-08T10:22:49Z")
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. ---
**Author:** ![tomderyck](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opentap.io/tomderyck/32/788_2.png) [@tomderyck](https://forum.opentap.io/u/tomderyck)\ **Post date:** [December 8, 2023, 12:51pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/9 "2023-12-08T12:51:36Z")
I base myself on [this explanation](https://www.continuousimprover.com/2022/02/gitversion.html). 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. ---
**Author:** ![alexander.larsen](https://avatars.discourse-cdn.com/v4/letter/a/9d8465/32.png) [@alexander.larsen](https://forum.opentap.io/u/alexander.larsen)\ **Post date:** [December 8, 2023, 2:23pm UTC](https://forum.opentap.io/t/gitversion-on-github/1317/10 "2023-12-08T14:23:17Z")
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.