-
Prerequisites
GitVersion packageGitVersion.Tool GitVersion versionOperating systemWindows What are you seeing?Hi. I ran into a problem when updating gitversion from 5.8.2 to 6.0.4 on our build server. The problem is that version for "old" branches (v-10, v-11, v-12) suddenly become to evaluate from tag inside default (master) branch. For example, master has the latest tag 20.1.5 and branch v-11 has its latest tag 11.7.0 so making a new commit into v-11 I expect to get version 11.7.1. So it was before upgrading to gitversion 6.0.4. After upgrade I have version 20.1.6. I spent some time on reading release notes/breaking changes with no luck. Then I started to check commit by commit in version history to localize the problem and have come to #3441. Consider taking https://github.com/destructurama/attributed repo as an example:
Now I expect 4.1.1 output from gitversion. My results (with stripped out time marks and execution time to make diff cleaner):
OK, 4.1.1
Not OK, 5.1.0. Since that commit I can observe such behaviour. I think that corresponding part of problem in logs can be seen here: 
For some reason gitversion become to use default branch instead of working branch.
What is expected?I expect gitversion to use tags from working branch when operating on that branch, not from default branch. Steps to ReproduceConsider taking https://github.com/destructurama/attributed repo as an example:
RepositoryFixture TestNo response Output log or link to your CI build (if appropriate). |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 9 replies
-
|
Actually, I would expect the version 5.1.1 as a result. This is the behavior I have tested with gitversion 6.3.0. The test branch is an unknown branch which will be treated almost like a feature branch (there are some difference). All tags on main are recognized when you are developing a new fetaure on e.g. a feature branch. Please see the GitFlow configuration: https://gitversion.net/docs/reference/configuration |
Beta Was this translation helpful? Give feedback.
-
|
After some research and debugging I decided to revert to previous behaviour by using such config workflow: GitFlow/v1
branches:
unknown:
increment: PatchDo you think this is the right path in my situation? |
Beta Was this translation helpful? Give feedback.
-
What do you mean with the commits from the future? If I'm not mistaken you have created a new commit on the unknown branch which is newer: gitGraph
commit id: "Initial"
commit id: "A" tag: "4.1.0"
branch unknown
checkout unknown
checkout main
commit id: "B" tag: "5.0.1"
commit id: "C" tag: "5.1.0"
checkout unknown
commit id: "D"
I think this is the responsible code path: If you have a branch with the value is-release-branch false and is-main-branch false, the algorithm considers the tags on the main branch. May I ask you why would you expect 4.1.1?
Obviosly this is not documented in the breaking change documentation. Maybe I have missed it. On the other hand I think this is not a feature (the previous behavior you are referring). Maybe we could introduce a new configuration property with name TrackMainBranches. @asbjornu: What do you think? |
Beta Was this translation helpful? Give feedback.
-
Yep, I've found that part of code in
Well, this was always the case and this is the expected and intuitive behavior for me. All commits above the branching point simply should not exist for the purposes of versioning when working on other branch IMO. I would like to have main (master) branch + N branches like v-1, v-2, v-3 tracking old corresponding versions each other. So all commits into v-1 produce versions like 1.0.1, 1.1.4, 1.3.34 and so on with locked major version 1. All commits into v-2 produce versions like 2.0.1, 2.1.4, 2.3.34 and so on with locked major version 2. All commits into v-3 produce versions like 3.0.1, 3.1.4, 3.3.34 and so on with locked major version 3. And main (master) branch goes further with any current version. Updating gitversion from v5.8.2 to v6 completely breaks this behaviour.
Honestly, I did not even expect that current behavior could be considered as desired. For now I'm looking for a way to fall back into previous 5.8.2 behaviour, i.e. not consider tags from main branch. What could you suggest? |
Beta Was this translation helpful? Give feedback.
-
|
Is this not exactly the use case of support branches? 
https://gitversion.net/docs/learn/branching-strategies/gitflow/examples#support-branches |
Beta Was this translation helpful? Give feedback.
-
|
And yet, I still do not understand why to use tags from the outer branch (master, main, whatever) on the current branch if these tags are after branching point. I admit that it may be really convenient for someone, but now it’s simply difficult for me to believe that such behavior is fundamental and is used everywhere. |
Beta Was this translation helpful? Give feedback.
-
|
We are talking about the behavior of unknown and feature branches where the algo detects tags of main branches. The reason why is, because you are developing on the newest stage (even if you haven't merge the main branch). At the end of the day the target branch of your unknown branch is the main branch. Probably you are talking about branches where you want to do hotfixes (of older releases). Why not just following the gitflow workflow which supports it already? Independently of that you are free to adapt the configuration settings by setting the is-release or is-main-branch property. I don't make any advice. |
Beta Was this translation helpful? Give feedback.
-
|
Also on the develop branch (as well as other branches) the name of the release branches are considered. If you have for instance a release/1.3.0 branch the resulting version would be 1.4.0 even if you haven't merged it. This is something you would probably not expect as well. 
|
Beta Was this translation helpful? Give feedback.
-
|
Wow. Thank you very much. Support branches is indeed the thing I want. I will use the second because this one because it more accurately expresses intentions. For now our support branches can have any name so for puposes of backward compatibility I will change regex for them to match any branch. Maybe in the future we will switch to Thank you again. |
Beta Was this translation helpful? Give feedback.
Is this not exactly the use case of support branches?
https://gitversion.net/docs/learn/branching-strategies/gitflow/examples#support-branches