Evaluate/Vote on GitVersion

[smudge202]

https://github.com/GitTools/GitVersion - yay/nay?

[herecydev]

Seems to dictate your git commit messages, so you lose readability for automatic versioning. With the project.json structure, you already have that baked in.

In both cases the developer is forced to confront versioning and manage that:

GitVersion	project.json
Automatic versioning	Automatic versioning
Commit messages/branch names must be observed in a PR	Git diff displays version change as normal
Reduced readability for commit messages	See above
Branch names are not flexible if using branch naming feature	Branch name dictates intent not version

Also possible Rollback/Rebasing cluster %$!" ?

[smudge202]

Wow. I was looking at GitVersion with tinted glasses it seems; I was greatly in favour on the premise @dennisdoomen has mentioned it a few times.

I don't think Dennis has delved too far into the ASP.NET 5 stuff yet, so your comparison may prove useful to both of us. THanks @herecydev.

[dennisdoomen]

I disagree. GitVersion doesn't require anything from the commits. It uses the branch names to determine the versions, provided you use Gitflow or GitHubFlow.

[herecydev]

@dennisdoomen how can you determine versioning before completing that feature branch?

[smudge202]

Would it be better to invert the question. At a glance, it seems you may need to hop through a couple hoops (albeit small ones?) to do stuff with GitVersion that project.json would give you more naturally. But what does GitVersion give in return.

[dennisdoomen]

@herecydev what do you mean?

[dennisdoomen]

@smudge202 For comparison, what does project.json do in terms of versioning?

[herecydev]

@dennisdoomen So, if I understand GitVersion correctly, you would have to name the branch with the version prior to coding that feature. If half way through you have to make a breaking change, then your branch name/version is broken.

[smudge202]

@dennisdoomen project.json itself doesn't do a great deal for versioning. It simply allows you to specify the version, though typically you'll use the version number 1.0.0-*. The wildcard would then be replaced during the build process by an environment variable set by the build server.

project.json doesn't hook into source control at all, and for the most part is no different to the old AssemblyInfo's; simply relying on standard CI/build server processes. Unfortunately (in my opinion) there is a lot of ugliness around NuGet versioning to which I believe project.json maintains.

I've only briefly looked at GitVersion but from what I can tell, versioning can be managed (and my associated thoughts on doing so) via:

• Version numbers in branches - Can't say I'm a fan of this. I prefer the branch names to better reflect the work being undertaken as opposed to a proposed version; especially in collaborative environments whereby branches may not be merged in the order they are created. That's not to say a branch can't be renamed before being collapsed I suppose?
• Git Tags - I could already do this in CI pipelines (natively supported through appveyor for example).
• yaml config - again, I could do this already by setting for example an environment variable for the build process in an 'appveyor.yml'.
• Track version of another branch - I don't really understand what this means, or a usage scenario for it?
• Merge messages - this seems the best way of the choices listed in my opinion. I do like the practice of release branches, though I suspect this was probably possible through CI again, albeit with some tinkering required?

I'd like to say, I'm neither for nor against GitVersion. Very much sat on the fence trying to work out what benefits it affords us?

[herecydev]

@smudge202 I think your underselling the project.json's versioning there! The version that you specify there will make the nuget package, file version and assembly version all equal to that version. That means no more inconsistencies in what nuget specifies vs assembly versions or caring about stamping the assembly version through your chosen CI pipeline.

Everything is taken care of through the same build tools that you need to build dnx. A simple dnu pack means building, versioning, and packaging into a nuget package in 1 step; that to me is utterly convenient.

[dennisdoomen]

So if project.json can update all the versions for you based on an environment variable, than GitVersion can help you generate those numbers without ever having to commit those numbers explicitly. I suggest you check out the examples to get an understanding of this.

[herecydev]

I'm a bit unsure how it can determine whether a feature is major, minor or a patch? I thought you had to explicitly declare +semver: major or +semver:patch etc.

[dennisdoomen]

By default, it assumes all features are backwards compatible and eventually land on the develop branch. Consequently it'll increment the minor version compared to the last tag on master. You can override that by updating the .yaml file or by explicitly naming the stabilization branch, e.g. 'release/2.0.0'.

[herecydev]

Isn't there an assumption that all features are "minor incrementing"? What if it's just a patch, e.g. 1.0.x?

[dennisdoomen]

Correct. A patch typically starts off from the master branch by creating a branch like hotfix/1.0.3. As soon as this branch is merged back to master, GitVersion will bump its version accordingly.

[ghost]

@herecydev side note: doesn't specifying --version on nuget.exe overwrite what is in project.json therefore making it again inconsistent? Just wondered as not tested it.

so it sounds and looks like:

hotfix/* branches increment patch feature/* branches increment minor release/* sets/overrides the version number.

Is that correct?

[herecydev]

@sblackler Well you don't use nuget.exe anymore, dnu is your all-in-one tool. Even if it's possible, being vigilant with PRs that change the build process should safeguard this.

[dennisdoomen]

I just realized I blogged about this a couple of months ago. It might help the discussion.

[smudge202]

I remember looking over that blog previously, and having scan read the associated GitFlow page. I took the time to read through both blogs properly this time. I'm in complete agreement with the GitFlow stuff, without having known about it we agreed upon that exact branching strategy at 4Com when I was working there.

I need to read a little more on GitVersion; I absolutely love the version tracking it does. The process was far too tricky for us to try and automate when we decided upon a branching strategy (though @mattridgway gave it a crack in TeamCity). I'm at this stage completely onboard with GitVersion and GitFlow was a given. I just need to see how GitVersion ties in with AppVeyor.

@herecydev , in my opinion GitVersion can work alongside project.json if you want. However, it might be easier to take any approach like Brad Wilson does with dev versions being set to 99999 though I think I'd prefer infrequently incrementing the majors (1.0.0-* -> 2.0.0-* when 1.* ships). We'd then utilise GitVersion in CI to populate the environment variables for versions when running dnu. Even nicer than that, we could apply that same step to local builds and GitVersion will correctly add unstable or feature based tags.