GitVersion produces different BuildMetaData once commit is tagged

[sebastianlux]

Repro Steps
First commit
Second commit <- Tagged with 1.2.0
Third commit <- pump minor via commit msg
Fourth commit

->Fourth commit now produces version number 1.3.0+2
-> Now tag the fourth commit with v1.3.0, aka we have released 1.3.0+2

Expected
When building the fourth commit, the exact same version information are produced by GitVersion, meaning 1.3.0+2

Actual
The fourth commit produces version information without any BuildMetaData, meaning the +2 is missing.

We usually take a build, test it, release it, and then tag the commit as released.
We do not know before the actual test whether we want to release (aka tag) the commit or not. But with this approach we are forced to tag the commit before the actual test to ensure that the version number of the commit does not change.

Edit:
Tested with GitVersion 3.6.5 and 4.0.0-beta0012

[sebastianlux]

Any update on this?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[jklaus]

I am seeing strange behavior with the metadata being off now as well. Started a couple weeks back.

[asbjornu]

With which version of GitVersion are you experiencing this, @jklaus?

[jklaus]

@asbjornu 5.0.1, in Azure DevOps.

[asbjornu]

Could you please update to version 5.3.4 and see whether the problem is reproducable there as well?

[jklaus]

I can investigate it but I think we're just using w/e the latest version is that the default build step installs. Not sure if it will allow me to download that far forward from where it currently is.

[jklaus]

@asbjornu scratch that.. looks like the step they're using has been deprecated. I'll tell them to install and port to the latest step, that's likely what the issue is.

[asbjornu]

I just realised that the "bug" experienced here is by design. A tag will reset the commit count. That's how GitVersion works.

[jklaus]

It used to behave such that it was commits ahead of mainline though.. not commits ahead of the current branch.

[jklaus]

@asbjornu - that said we've been on 5.0.1 for a very long time w/o issues until recently so I assume the issue is more rooted in either the version of .Net Core 2.1 that our agents are installing or something else ADO/agent specific. That said, I'm going to have them port from GitTools.GitVersion to GitTools.UseGitVersion which should bring in the latest GitVersion version and will reassess. Its worth noting that they're currently creating release branches for things in the RC phase so we have a bit of a customized GitVersion.yml around that. Using branch naming as a methodology to determine major, minor, or patch incrementation. That said, all of this worked fine with GV version 5.0.1 up until probably a month or two ago now. The only thing that has varied in that timespan is whatever changes MS has made to the ADO hosted agents. They're constantly rolling out patches to .Net Core 2.X/3.X so I suspect the version of that we're getting now isn't playing well with an old version of GV.

[asbjornu]

@arturcic, is UseGitVersion the recommended way to use GitVersion in AzDO these days?

[arturcic]

Well I would recommend to give a try the GitTools version, and fill in issues, as that's the way to go. As for the UseGitversion, we don't have resources to fix it

[jklaus]

@arturcic - are there known issues with UseGitVersion? I've tried leveraging it on a .Net Core 3.1 build and its having issues installing. The agents are currently pulling .Net Core 3.1.300, GitVersion 5.3.4.

[HHobeck]

Gitversion Version:
5.3.4+Branch.master.Sha.be48ce3ac7f048c869fe80b8c8e648ebf4a7e360

User Story:
I'm using gitversion and use the GitFlow workflow as a merging branching strategy. This works quite well as soon the version labeling and the release merging in master comes in place. My build and release workflow is like the reporter of this issue. That means I create a release candidate (RC) e.g. 2.4.0.3 in a releases branch and going to test it somehow in the test environment. After this version has been proofed I define it as release to manufacturing (RTM) and deploy the exact same artifacts on the production environment and create a nuget package 2.4.0 containing the 2.4.0.3 DLLs. Note no new artifact has been compiled on master or somewhere else. Now I merge the version from releases branch to master, create a label (with three or four numbers depending if I merge with --no-ff) and delete the releases branch. At this point the source code in master is the same like I had in the releases branch before. I know it is possible that the version differs because of hotfixes in master but I ensure this in my process using git cherry -v origin/releases/2.4.0 origin/master command before merging. If I take the labeled source code from master I get the version 2.4.0.0 instead of 2.4.0.3.

P.s.:
@asbjornu: I'm not sure if it is a bug or an unsupported feature. But just to say it is by design without taking further actions is for me not acceptable. I can tell you that in my opinion gitversion has been developed to support the process of creating product version including semantic versioning. In my case I'm still convenient with the semantic version process because the semantic version number comes in place at this moment I create a nuget package. We should think about it to introduce a new field or something like that to support the release version with four numbers with last number greater or equal to zero and not only the semantic version with three numbers.

P.p.s.:
At this moment the version of gitversion is quite buggy. Sometimes it creates no zero after labeling and sometimes it does. If it is per design why it behaves not consistently?

P.p.p.s.:
I'm also a little bit afraid about the discussion above. This issue has nothing to do with integration into azure devops. And also this issue is marked as a bug. This issue is about that the last number is zero or at least the metadata is missing after labeling. I think we have two or three issues here mixed up in one issue.

P.p.p.p.s.:
This issue is so important in my opinion because the current version of gitversion restricts the release manager in that way that he or she has to create a new artifact with a new version on master before releasing it. Thus you always going to release a version which is not tested at all and can be full of bugs because for instance somone changed the build pipeline. This scenario is not what you want happening in a production system. That's why you release the RC version and define it as RTM.

Gitversion.yml:
assembly-versioning-scheme: MajorMinorPatchTag
assembly-versioning-format: '{MajorMinorPatch}.{CommitsSinceVersionSource}'
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-file-versioning-format: '{MajorMinorPatch}.{CommitsSinceVersionSource}'
assembly-informational-format: '{MajorMinorPatch}+{Sha}'
mode: ContinuousDelivery
branches: {}
ignore:
sha: []
merge-message-formats: {}

[asbjornu]

@jklaus: Please use the GitTools Task instead of UseGitVersion. The latter is not maintained.

[asbjornu]

@HHobeck, just to be clear, when you write "label" do you mean git tag?

[HHobeck]

@asbjornu: Yes that is what I mean. If I label the released source code in master I use the command git tag 2.0.4.3 for instance. It might be also an idea to use just git tag 2.0.4 and let gitversion find out the last number.

[asbjornu]

@HHobeck, I don't think GitVersion plays well with four-part version numbers. GitVersion supports SemVer 2.0 which only has major.minor.patch and an optional pre-relase label separated with -.

If you want to support four-part version numbers you can do that by customizing the format, but that is only used for how GitVersion serializes version numbers and does not affect its internal modus operandi, such as calculation.

[HHobeck]

@asbjornu: Yes I understand that for the current version of GitVersion. If you ask me GitVersion should support a revision number in future releases. I mean semi versioning comes in place at this point you create a final package for the end user. That's good. But that is the point the process of creating software is much more complex and not just about creating a final package. The semi version number is just a small part of it. The scenario I have described is quite common and it's a shame that GitVersion is not supporting it.

[asbjornu]

I wouldn't oppose GitVersion supporting this, but I don't think you can wait for anyone else to implement this for you. If you want to spend time implemeting this, adding required tests, etc., I would be happy to merge it, provided it doesn't break any of our existing supported use cases.

[arturcic]

@asbjornu: Yes I understand that for the current version of GitVersion. If you ask me GitVersion should support a revision number in future releases. I mean semi versioning comes in place at this point you create a final package for the end user. That's good. But that is the point the process of creating software is much more complex and not just about creating a final package. The semi version number is just a small part of it. The scenario I have described is quite common and it's a shame that GitVersion is not supporting it.

@HHobeck I would prefer not to see "shame" in anyones comments, especially if it's related to the decisions made by maintainers of a project. As the repository's description says - Easy Semantic Versioning (http://semver.org) for projects using Git - we support Semantic version, that was the intention of the project. It's not a tool that can handle any versioning schemas usable today in software development.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.