Inconsistent output from documentation

[profet23]

According to the documentation here: MSBuild Task Usage
If you tag the commit before head with v1.2.3 and then build head, the AssemblyFileVersion should be: 1.2.3.0
But when this is done the AssemblyFileVersion is actually: 1.2.4.0
Which is correct?
Not sure if this is a documentation bug or a product bug.

The documentation also states that with the example above the AssemblyInformationalVersion will be:
1.2.4+1.Branch.<branchname>.Sha.<commithash>
Is that the desired behavior? Or should it be:
1.2.3+1.Branch.<branchname>.Sha.<commithash>
As this version would be 1 commit ahead of 1.2.3

[StanleyGoldman]

+1

[JakeGinnivan]

Think it is a doco issue. Where abouts?

If you tag a commit, that commit will stay the same as the tag but the commit after the tag will bump the patch version.

Sent from my Windows Phone

---

From: Stanley Goldmanmailto:notifications@github.com
Sent: ý20/ý02/ý2015 08:36
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Subject: Re: [GitVersion] Inconsistent output from documentation (#374)

+1

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/374#issuecomment-75247146.

[JakeGinnivan]

Oops, just read past the link. The doco there is inconsistent, in the same line it says 1.2.3 and 1.2.4.

It should definitely say 1.2.4 everywhere if the last tag is 1.2.3

Sent from my Windows Phone

---

From: profet23mailto:notifications@github.com
Sent: ý20/ý02/ý2015 08:35
To: ParticularLabs/GitVersionmailto:GitVersion@noreply.github.com
Subject: [GitVersion] Inconsistent output from documentation (#374)

According to the documentation here: MSBuild Task Usagehttps://github.com/ParticularLabs/GitVersion/wiki/MSBuild-Task-Usage
If you tag the commit before head with v1.2.3 and then build head, the AssemblyFileVersion should be: 1.2.3.0
But when this is done the AssemblyFileVersion is actually: 1.2.4.0
Which is correct?
Not sure if this is a documentation bug or a product bug.

The documentation also states that with the example above the AssemblyInformationalVersion will be:
1.2.4+1.Branch..Sha.
Is that the desired behavior? Or should it be:
1.2.3+1.Branch..Sha.
As this version would be 1 commit ahead of 1.2.3

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/374.

[StanleyGoldman]

I'm having trouble understanding how this is correct. If this is in fact correct, how can I still use GitVersion and have things done my way?

Basically I would only like to update the Patch number when i tag it as such. Until then, I'd rather only have the commit count number incremented.

In other words... when looking at this image. I would expect a5f6c5 to read 1.0.0+1 not 1.0.1+1.

My thoughts are also confirmed by the output of git-describe. In the scenario above, git describe would return 1.0.0-1-a5f6c5

[JakeGinnivan]

GitVersion is always pre-emptive with it's versioning. i.e you are building candidates for the next release

That with the fact that it is SemVer, not normal versioning means that when you tag you have released that package. So we automatically increment because no point building the same version which has already been released.

Make sense?

[StanleyGoldman]

I've used this project for some time, I recommended it to @profet23 and he pointed out this issue to me. I've tried to make sense of this issue since then and I cant seem to see things your way.

In my scenario I'm looking at automatically deploying a development build to a development server.

When I want to know what version this development build is, 1.0.0+1 clearly indicates 1 commit past 1.0.0 tag. 1.0.1+1 makes me think to look for a 1.0.1 tag, then when I don't find one, I look for a 1.0.0 tag and look one commit past it.

My other problem is yes, I haven't released yet, I haven't determined if I'm making a new Patch, a new Minor or a new Major. But GitVersion increments the build as if it knows I'm producing a new Patch version.

I realize I'm probably not going to convince you, since this isn't a matter of right/wrong, it's more a matter of personal preference and what works for you and your organization.

Therefore, I think it should be a configuration option, EnablePreemptiveVersioning for lack of a better name. I would be willing to make the changes and send a pull request. I would need some direction from you to identify where the "preemptive version decision" occurs.

If you disagree that it should be a configuration option, I wouldn't mind the same direction, to identify where the "preemptive version decision" occurs. Because then I can roll my own version of GitVersion.

[JakeGinnivan]

I'm not against adding a configuration option, I just need to understand :)

Here is a breakdown of the way I have my projects setup: http://jake.ginnivan.net/blog/2014/07/09/my-typical-teamcity-build-setup - have a read of that, it might help understand why it works the way it does.

Now, in regards to the issue there are a few questions we need to answer:

1. You always do a rebuid when you do a release?
2. You do not use release pre-release packages?
3. If non-tagged commits calculated a 4 part version where the 4th part was the commit count would that improve things?

The main issue I see is that if we build the same version as the last tag, then the artifacts from that build cannot be published. And if a pre-release is generated it will be a lower version than the released version?

As a side note, v3 was rewritten because many of the original assumptions do not work for all people. Based on a lot of conversations with people I made everything configuration driven and it now works for all the scenarios I know/understand at the moment. Hopefully we can get to the bottom of this and make it work for you.
Once we figure it a pull request to improve the readme based on your issues would be super useful!

[JakeGinnivan]

Another small note in relation to

My other problem is yes, I haven't released yet, I haven't determined if I'm making a new Patch, a new Minor or a new Major. But GitVersion increments the build as if it knows I'm producing a new Patch version.

We can assume this, and if at any point a pull request makes a minor/major change then the next-version configuration option can be set to increment the version. We also were thinking about having new strategies for this, for instance:

My commit message minor++ could trigger a minor version bump. This means the version which is being built is always the version of the next version as it stands at that point in time

[StanleyGoldman]

Thanks for being responsive, you've given me a lot to think about.

I've used GitVersion for much simpler scenarios than the one I'm undertaking now.

My organization is currently adopting CI practices and I'm tasked with planning and documenting a branching/merging strategy as well as a versioning strategy.

We've settled on using GitFlow as our workflow, but I realize I have a bit more to understand with GitFlow in respects to versioning. I'll come back to you when I know more.

[MeirionHughes]

Have a look at SourceTree. You can "enable" GitFlow on a repository after which SourceTree will present you with options for Creating/Closing Release, Feature and Hotfix branches. I found it super easy to adhere to GitFlow with this. Also, SourceTree is simply better at letting you stage changes for a commit - specifically splitting your per-file changes into separate commits

[JakeGinnivan]

@StanleyGoldman feel free to ping me if you have more questions

[JakeGinnivan]

@StanleyGoldman it has taken me over a year of building this to get my head around a lot of the problems, it's not the simplest space. I hope to write more doco soon