Replies: 1 comment 5 replies
-
How does removing |
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have done a lot of reading in the repo and I understand that by design, GitVersion will always choose the highest version number it calculates. However, I find this behavior very frustrating and I'm not able to get the result that I want.
I'm using v5.10.3. Here is my
GitVersion.yml
:And the git log:
When I run
gitversion
I expect version0.1.1
, but instead I get1.0.3
. It appears that it continues to count commits before the tagged commit, which I wasn't wanting it to do.Here are the logs of
gitversion /diag
:Of particular interest is this bit:
My understanding is that PR #3078 should have prevented GitVersion from looking at commits before the last tag. I'm trying to force GitVersion to use a zero-based major version until I'm ready to formally release the API. There's no first-class mechanism to support this, so I've just tried to be careful about not introducing
BREAKING CHANGE
/feat!
or similar type commits. However, there are commits prior to the introduction of GitVersion that unfortunately were done wrong, and those impact the major version when I do not want them to.To make things worse, I tried this but these settings seem to have no impact:
How can I get the version to be
0.x.y
again using Mainline mode?Beta Was this translation helpful? Give feedback.
All reactions