Question about asserted version

[gep13]

No description provided.

[gep13]

@JakeGinnivan I wanted to follow up with a conversation that we were having in Gitter:

https://gitter.im/GitTools/GitVersion?at=56c731e2833e58f50fb02b46

When I started digging into the code, I saw that you have a Test that covers the scenario that I was trying to describe, namely a release branch, with no commits, which is merged to Master, but not back to develop, as it is not required.

In the test, once you checkout the develop branch, you immediately do a commit, which results in the correct version number. However, if you don't first do a commit, then you get an invalid version number.

Is this expected? I would have thought that this should have asserted 1.1.0-unstable.0 not 0.1.0-unstable.3

What do you think?

[gep13]

@JakeGinnivan just wanted to touch base to see if you had any thoughts on this one? Thanks!

[JakeGinnivan]

It is not expected and it probably should be a scenario which is fixed. Haven't had a chance to look into reasons why it doesn't work or give theorys why its failing though.

[JakeGinnivan]

Had a quick look into it, unfortunately the track merge targets part of GitVersion is something I don't quite understand :)

Here are the logs from before/after

// Commented out commit
INFO [04/10/16 10:04:10:50] Using latest commit on specified branch
INFO [04/10/16 10:04:10:63] Running against branch: develop (8ce2d0ff7f7d26013011e98832f4bec7b216b95f)
INFO [04/10/16 10:04:10:64] Begin: Calculating base versions
  INFO [04/10/16 10:04:10:68] Fallback base version: 0.1.0 with commit count source a01f2529d04bc215fde09aa15449fe73bb3a51e7
  INFO [04/10/16 10:04:10:80] Base version used: Fallback base version: 0.1.0 with commit count source a01f2529d04bc215fde09aa15449fe73bb3a51e7
INFO [04/10/16 10:04:10:81] End: Calculating base versions (Took: 164.12ms)
INFO [04/10/16 10:04:10:82] Skipping version increment
INFO [04/10/16 10:04:10:83] 3 commits found between a01f2529d04bc215fde09aa15449fe73bb3a51e7 and 8ce2d0ff7f7d26013011e98832f4bec7b216b95f
*   775ebcc 51 minutes ago  (tag: 1.0.0, master)
|\  
| * 8ce2d0f 52 minutes ago  (HEAD -> develop)
| * 5ac059d 54 minutes ago 
| * 2e6ba13 56 minutes ago 
|/  
* a01f252 58 minutes ago 

// Not commented out
INFO [04/10/16 10:10:08:04] Using latest commit on specified branch
INFO [04/10/16 10:10:08:21] Running against branch: develop (51f9676adc2d876ad94d99ea55f5935facfdb0e0)
INFO [04/10/16 10:10:08:22] Begin: Calculating base versions
  INFO [04/10/16 10:10:08:27] Fallback base version: 0.1.0 with commit count source 5495ab19470f61411fc59edaa0190baaf1180f51
  INFO [04/10/16 10:10:08:38] Merge target tagged '1.0.0': 1.0.0 with commit count source 29214f1eb8ea49a68e6f9ed0e52660a630399f7b
  INFO [04/10/16 10:10:08:39] Merge target tagged '1.0.0': 1.0.0 with commit count source 29214f1eb8ea49a68e6f9ed0e52660a630399f7b
  INFO [04/10/16 10:10:08:42] Found multiple base versions which will produce the same SemVer (1.1.0), taking oldest source for commit counting (Merge target tagged '1.0.0')
  INFO [04/10/16 10:10:08:42] Base version used: Merge target tagged '1.0.0': 1.0.0 with commit count source 29214f1eb8ea49a68e6f9ed0e52660a630399f7b
INFO [04/10/16 10:10:08:42] End: Calculating base versions (Took: 203.14ms)
INFO [04/10/16 10:10:08:44] 1 commits found between 29214f1eb8ea49a68e6f9ed0e52660a630399f7b and 51f9676adc2d876ad94d99ea55f5935facfdb0e0
* 51f9676 49 minutes ago  (HEAD -> develop)
| *   29214f1 51 minutes ago  (tag: 1.0.0, master)
| |\  
| |/  
|/|   
* | 347a766 52 minutes ago 
* | 1c43c9e 54 minutes ago 
* | fdc8d85 56 minutes ago 
|/  
* 5495ab1 58 minutes ago 

So just need to figure out how we can make the merge tracking branch target thingo pick up that tag when develop has not moved on

[gep13]

@JakeGinnivan thanks for starting to look at this!

[JakeGinnivan]

Ok, so I can give you a real answer now that I have changed the way this works in #832

The reason it will not bump is because the tag is made after the commit. We only include tags made before the commit which we are calculating are made.

I have now removed that check so all tags on master affect develop. This does mean that develop can jump based on other things happening, so rebuilds can change versions which doesn't happen on other branches.

[gep13]

@JakeGinnivan ok, understood. Thanks for digging into this!