Use git notes instead of nextversion.txt

[joshka]

Hiya,
This is a suggestion that I'm putting here more for discussion purposes and a record for why you might / might not implement it.

I've always been a little uncomfortable with the idea that information like what the version number of the software belongs directly in the repo / branch (in a variety of SCMs) as this number is almost certainly wrong some of the time (e.g. building the same source on my machine with different settings should never produce a version that matches the version created on a build server.)

Git however supports metadata stored in the form of git notes.
A good overview of this can be found at http://alblue.bandlem.com/2011/11/git-tip-of-week-git-notes.html with some info on how gerrit uses something similar. I think this would solve some of the problem. Thoughts?

[JakeGinnivan]

Hey Josh

I have thought about this, in GitVersion (which is very close to completely superseeding this project, it just needs a few more things done to bring to parity) we want to support versioning strategies. NextVersion.txt is one, notes looks like it would be a good one, then also using commit messages as well. See GitTools/GitVersion#137 for the commit messages idea.

I would like to dive into the comment about being uncomfortable with version being linked to repo/branch. I actually feel the opposite, I think version information should be linked source. I am not a huge fan of checking in a file though, where notes could help. That link is pretty helpful, I don't really know much about notes so will read up.

Just clarifying, you are mainly talking about the fact you have to check-in a file to bump the version, or if we are talking about version information coming from Version Control rather than the Build server? The main issue with your build server owning the version is this situation:

I release v1.8 with a new feature, then release v2 with a bunch of breaking changes. There is a new bug in v1.8, so I branch from the v1.8 tag, fix it, I want the build server to build v1.8.1, often this means changing the build server config.

With GitVersion the fact that you are commiting off a branch where the highest tag on master with a common ancestor will be 1.8, means that we are patching 1.8 by convention, so the version will automatically be 1.8.1.

I do agree that local builds will produce the same version as the build server, but not sure that is a problem. I like the fact I can change my build process, fully test locally, then push it.

Also, what sort of settings would you envision being changed from the build server build vs the local?

If you could clarify the bits you are uncomfortable with, I will transfer this issue to the GitVersion repo, as I won't be fixing anything in this project anymore really.