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.
-
|
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Prerequisites
GitVersion package
GitVersion.Tool
GitVersion version
bb071c0
Operating system
Windows
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:
testfrom tag 4.1.0Now 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:
What is expected?
I expect gitversion to use tags from working branch when operating on that branch, not from default branch.
Steps to Reproduce
Consider taking https://github.com/destructurama/attributed repo as an example:
testfrom tag 4.1.0gitversion PATH_TO_CLONED_REPO /diagon b0f6c77 (outputs 4.1.1)gitversion PATH_TO_CLONED_REPO /diagon bb071c0 (outputs 5.1.0)RepositoryFixture Test
No response
Output log or link to your CI build (if appropriate).
Beta Was this translation helpful? Give feedback.
All reactions