Hotfix resets PreReleaseTag.Number to 1

[mjamin]

From the gitflow examples:

develop might've been at 1.3.0-unstable.2 before the hotfix, but as soon as the hotfix is merged, GitVersion resets the number to 1.3.0-unstable.1.

We build NuGet packages off of our develop branch (e.g. 1.3.0-unstable0002) and if the counter resets, people won't get any updates.

Edit: using ContinuousDeployment on develop

[JakeGinnivan]

Would you have time to look into this, or at least create a failing test? I am short on time at the moment (moving back to Australia in two weeks).

[mjamin]

Behaviour with the default config of the latest GitVersion:

1. master is at 1.2.0 (tagged).
2. I continue to work on develop and add a commit. The version is now 1.3.0-unstable.1.
3. Now I create a hotfix based on 1.2.0 and merge it back to both branches. master is now at 1.2.1, but develop is at 1.3.0-unstable.0.

This is because the commits are counted since the hotfix merge commit due to the MergeMessageBaseVersionStrategy (commit message is Merge branch 'hotfix/1.2.1' into develop). Since that is the commit we're currently on, the count is zero.

If I disable the merge message strategy it works as desired in my case, because now HighestTagBaseVersionStrategy delivers the base version and since we only tag on master all commits on develop since the last release are counted. edit: not true.

But I have no idea what to do with that information :)

Should BaseVersionStrategies be configureable in some way? Should I avoid using a version in my hotfix branch name? Does the merge message strategy need to be adjusted? Is the MetaDataCalculator not clever enough? Maybe choosing the highest version from all strategies is too simple?

[mjamin]

I just discovered the HotfixBranchScenarios Fixture and the PatchLatestReleaseExample seems to be the exact case I am describing. It also asserts that the version of develop is 1.3.0-unstable.0 after merging the hotfix, although it was 1.3.0-unstable.1 before. So this seems to be by design.

But this leads to multiple different releases of e.g. 1.3.0-unstable.1.

[JakeGinnivan]

Ok, so I have partially fixed the problem, now am not sure where to go (I can sort the implementation, but I just cannot figure out the rules..).

Lets take this commit graph:

      Test Commit for file 'd423d32f-d2a8-4dfd-a945-094d72c74f91'
*   commit 1141e4e (HEAD, develop)
|\  Merge: e42e19a 7f4c7cf
| | Author: A. U. Thor <[email protected]>
| | Date:   50 minutes ago
| | 
| |     Merge branch 'hotfix-1.2.1'
| |       
| | *   commit a18b692 (tag: 1.2.1, master)
| | |\  Merge: a738a4c 7f4c7cf
| | |/  Author: A. U. Thor <[email protected]>
| |/|   Date:   51 minutes ago
| | |   
| | |       Merge branch 'hotfix-1.2.1'
| | |    
| * | commit 7f4c7cf (hotfix-1.2.1)
| | | Author: A. U. Thor <[email protected]>
| | | Date:   53 minutes ago
| | | 
| | |     Test Commit for file '981d91c1-07b9-4006-b8d8-87718427b541'
| | |    
| * | commit 59990cf (tag: 1.2.1-beta.1)
|/ /  Author: A. U. Thor <[email protected]>
| |   Date:   55 minutes ago
| |   
| |       Test Commit for file 'ab417606-c049-4ae7-a491-23252d8cc8dc'
| |   
* | commit e42e19a
|/  Author: A. U. Thor <[email protected]>
|   Date:   57 minutes ago
|   
|       Test Commit for file '260d6ef5-2431-4b50-9819-2f37f45499ad'
|  

We are trying to calculate the version from 1141e4e. Before the merge commit the source was the tag 1.2.0 @ a738a4c
After the merge commit the source is 1.2.1 @ a18b692 because that follows gitflow rules.

Both 1.2.0 get incremented to 1.3.0 and both are 1 commit away from the Tip of develop, so we get the same version.

Maybe I could do something like when I see a merge commit source I take the first parents source. Interesting issue :(

[mjamin]

I thought maybe instead of simply finding the highest baseversion, find the highest baseversion with the lowest patch value, if we are on a branch that has the increment strategy set to minor.

But that did break some tests and I stopped there.

[JakeGinnivan]

That could work if you also check the ShouldIncrement flag.

[JakeGinnivan]

I think the logic for finding the base version is correct. What is incorrect is picking the source for commit counting.

If we separate those two things then this might become easier. The road I was heading down is just leading to pain, I am going to stash that and try again later

[JakeGinnivan]

And the logic for commit counting should be something along the lines of:

1. Calculate base version (as we do now)
2. Find all other base versions which will have the same incremented version number
   2a) If there are no conflicts, all good we can just use that source
   2b) If there are conflicts this is where we need to go back to the previous source

Thoughts?