Uhm, where did the source control subforum go? Nice to have a modern-looking gamedev.net indeed!

Ok, let's get to the real deal. At my current job I have somewhat managed to get to something useful and to be released. I always had an issue with versioning and so I just installed GitVersion, the relative tools and its automatic MSBuild thingie GitVersionTask.

Leaving aside I'm meeting some resistance in using source control at all, our team is so small there's really no point in using anything more than the old merge/branch model. Software development around here is... curiously managed to say for the least so I had the following needs:

1. Official builds marked as major.minor.patch
2. Unofficial builds as (1) plus unique identifier. SHA would be perfect.

So, what I do: I merge off master to work on something, when I merge back to master that would be a 'build'. Whatever that build is released to public or not is not my concern: stuff in master is ideally official. It seems like mainline development should be my thing right? Wrong. I tried countless configurations and wasted about three hours today the end result is always some variation of (output in VS build).

Quote

Version '7.2.3+Branch.master.Sha.<snip>' specified for 'product version' is not in normal format 'major.minor.build.revision'.

My gitVersion.yml:

next-version: 7.2
mode: Mainline

I tried annotating the master branch by using gitVersion.yml 'branch:' subsection with no avail. I have however confirmed the file is being consumed by successfully altering the produced major/minor and by producing errors.

I am a bit reluctant in opening an issue on the project page as it's basically certain it's something by my side.

What am I missing?

By the way, after all this pain I might actually consider other versioning mechanisms. All sort of suggestions are welcome.

23 hours ago, Alberth said:

git itself also has some features to name an arbitrary commit, which may be useful. I think it's "git id", but not sure, and I can't easily look it up.

There are indeed a variety of ways, I know them as 'tags' and in theory they work... except for some reason they really don't in this specific case. I use sourcetree so it's just a matter of pushing a button.

23 hours ago, Alberth said:

I am not so sure your "2" makes sense, for branches, you definitely want a branchname in there, since 1.2.3.abcdf has no meaning at all to understand what branch the build contains.

Well the snip is a full SHA and I've had a collision already in the past (not on SHA) so I feel quite safe for the next few years! They are indeed almost unique.

23 hours ago, Alberth said:

In my experience, the primary profit of a VCS it is that you don't need to copy changes back and forth between developers. Secondary benefits are that you have a list of changes since the last commit nearby, and it's easy to revert to that last state, so random experiments in debugging or trying something unknown are safe. Unfortunately, git pushes you in the distributed development model, which is not always as useful as they claim

Absolutely true. I'd say this problem is orthogonal to being distributed or not (compare P4 or other old stuff). For our environment it's fairly convenient to have a bare repository on a shared folder: ideally we don't push short lived branches there - ideally we sync no more than a couple of times a week and push a full untagged branch with explicit merge commits. I suggest everyone to have a go; my experience with git is positive albeit I used to have a thing for Mercurial.

Maybe I should have made clear that GitVersionTask stamps your c# executable with proper versioning by looking at the git. It isn't even just a property setting: you can inspect the result programmatically.

Anyhow, I had been given unwelcome news today so I'll be slow on replying. Given my new schedule, I think I might just give up on GitVersionTask and go back on explicit version stamping. Inconvenient but I have already spent too much time in figuring out what's wrong there.