GitHubFlow patch number isn't incrementing as expected

[seankearney]

I've read through #205, and specifically this comment, and I'm not seeing expected behavior with GitVersion + GitHubFlow. Please see the following steps I've taken (in git bash) and the output given by GitVersion. It appears, to me, that the <commitcount> is being incremented, not the <patch>. Can someone tell me if the output below is expected?

git init
echo 0 > file.txt
git add .
git commit -m "initial"

GitVersion.exe --> 0.1.0+0

echo 1 >> file.txt
git add file.txt
git commit -m "second"

GitVersion.exe --> 0.1.0+1

git checkout -b featureA
echo feature >> file.txt
git add file.txt
git commit -m "feature"

GitVersion.exe --> 0.1.0+2

git checkout master
git merge --no-ff featureA

GitVersion.exe --> 0.1.0+3

echo 1.0 > NextVersion.txt

GitVersion.exe --> 1.0.0+3

git add NextVersion.txt
git commit -m "Version 1"

GitVersion.exe --> 1.0.0+4

This release was deployed As per the aforementioned thread, the repo is now tagged...

git tag -a v1.0.0 -m 'Version 1.0.0'

GitVersion.exe --> 1.0.0+0 I understand this, but does seem backwards... I release 1.0.0+4, but after I tag it that same release would be 1.0.0.

git checkout -b featureB
echo featureB >> file.txt
git add file.txt
git commit -m "feature b"

GitVersion.exe (in featureB) --> 1.0.1+1 <patch> went up!

git checkout master
git merge --no-ff featureB

GitVersion.exe (in master) --> 1.0.1+2

git checkout -b featureC
echo featureC >> file.txt
git add file.txt
git commit -m "feature c"

GitVersion.exe (in featureC) --> 1.0.1+3 <patch> didn't go up!?!?

git checkout master
git merge --no-ff featureC

GitVersion.exe (in featureC) --> 1.0.1+4

[andreasohlund]

Agree that the +4 going down to 0 when the tag is applied is confusing. I'm +1 for condidering that as a bug?

The patch going up on the next commit seems ok to me since the tagged commit is 1.0.0 and it will only move to 1.0.1 on the next commit?

Sent from my iPhone

On 13 Aug 2014, at 17:42, Sean Kearney [email protected] wrote:

I've read through #205, and specifically this comment, and I'm not seeing expected behavior with GitVersion + GitHubFlow. Please see the following steps I've taken (in git bash) and the output given by GitVersion. It appears, to me, that the is being incremented, not the . Can someone tell me if the output below is expected?

git init
echo 0 > file.txt
git add .
git commit -m "initial"
GitVersion.exe --> 0.1.0+0

echo 1 >> file.txt
git add file.txt
git commit -m "second"
GitVersion.exe --> 0.1.0+1

git checkout -b featureA
echo feature >> file.txt
git add file.txt
git commit -m "feature"
GitVersion.exe --> 0.1.0+2

git checkout master
git merge --no-ff featureA
GitVersion.exe --> 0.1.0+3

echo 1.0 > NextVersion.txt
GitVersion.exe --> 1.0.0+3

git add NextVersion.txt
git commit -m "Version 1"
GitVersion.exe --> 1.0.0+4

This release was deployed As per the aforementioned thread, the repo is now tagged...

git tag -a v1.0.0 -m 'Version 1.0.0'
GitVersion.exe --> 1.0.0+0 I understand this, but does seem backwards... I release 1.0.0+4, but after I tag it that same release would be 1.0.0.

git checkout -b featureB
echo featureB >> file.txt
git add file.txt
git commit -m "feature b"
GitVersion.exe (in featureB) --> 1.0.1+1 went up!

git checkout master
git merge --no-ff featureB
GitVersion.exe (in master) --> 1.0.1+2

git checkout -b featureC
echo featureC >> file.txt
git add file.txt
git commit -m "feature c"
GitVersion.exe (in featureC) --> 1.0.1+3 didn't go up!?!?

git checkout master
git merge --no-ff featureC
GitVersion.exe (in featureC) --> 1.0.1+4

—
Reply to this email directly or view it on GitHub.

[JakeGinnivan]

The disjointed commit counting is because we treat the tag as an absolute version, for the cases that you migrate your repository and rebuild old tags we have to adhere to that tags version.

If you tagged with this command instead:

git tag -a v1.0.0+4 -m 'Version 1.0.0'

Then it would maintain that metadata.

The next point is that GitVersion is designed to work with continuous delivery (expecially with GitHubFlow), take this scenario:

• Start feature which is breaking, so update NextVersion.txt to bump major
• That feature branch now builds with a bumped major
• Feature branch is merged into master, master now is building with bumped version
• Fix bugs, add other non-breaking changes - still only the major should change
• Release
• If we rebuild that tag, we want the same version we released (if you want to keep metadata, it should be tagged too)
• Next commit bumps patch because:
  • If we bumped minor, there is no way to drop that to a patch release without using a hotfix branch
  • NextVersion.txt can be used to bump minor if there is a feature added
• Master is now building the next release candidate if you will, which at some point you can just deploy

Does that make sense? Now that is the why things are like they are now, suggestions to improve are welcome :)

[JakeGinnivan]

Also see #186 (comment) for more info on the decision about how we treat tags

[seankearney]

I was looking for the same outcome as @Zoltu which was to bump patch with every commit, but that isn't what is going to happen.

I went back and re-re-read the thread I linked to. The rule, simply put, is that the first commit after a tag bumps the minor. All other commits simply bump <commitcount>. Bumping <major> or <minor> requires changing the NextVersion.txt file.

Also, @JakeGinnivan the tip about keeping the meta in the tag makes sense... the tag is created after the build so it would be known and should be used.

[MicahZoltu]

I'm not meaning to step on anyone's toes here or be rude, so please delete this comment if it is against OSS etiquette.

@seankearney After trying to get GitVersion to do what I wanted I eventually went and wrote my own versioning NuGet package that does what I want, which is update the patch with every commit and the major/minor based on tag. The requirement is that you have to tag before you release. This likely means your CI process tags on checkout before build or you tag before you push your local repo. I recognize that this doesn't fit well into most people's versioning models so GitVersion is probably a better choice for them.

That being said, if you want patch version auto-counted by commit and major/minor based on the nearest tag, check out https://github.com/Zoltu/Zoltu.Versioning and https://www.nuget.org/packages/Zoltu.Versioning/

In my case, if I have a commit that adds a feature or makes a breaking change then I tag before I push. In all other cases I don't think about versioning.

[JakeGinnivan]

@seankearney @Zoltu the thing is that GitVersion was designed for semantic versioning, and commits != releases.

If the need is to bump the version every commit, then use the GitVersion_ClassicVersion variable which will make the semantic version of 1.2.3+4 -> 1.2.3.4

This satisfies the requirement of bumping the version every commit, but not the semantic version.

We have also discussed a flag which switches GitVersion into this mode?

Suggestions are welcome, but also information about the problems you are having/trying to solve would be handy in finding the solution which works?

[seankearney]

@JakeGinnivan My scenario was much like @Zoltu. I was looking to release (almost) every commit and saw the tagging requirement a bit much as it would (potentially) lead to tagging every commit.

The reality, for me, is that I am not using this in a publicly consumed API and the version doesn't matter so much, so long as 1) it changes and 2) can identify the code at a specific time. It meets both criteria.

This question/thread could have been avoided if I had fully understood what was said in #205. I understand why GitVersion is behaving as it does. Thanks.

[JakeGinnivan]

Might be worth me adding this sort of scenario in the readme/wiki. It makes sense for a lot of projects, just not something we have looked into much.

Having people read closed issues will not really scale :)

Have created #242 to track this issue, what do you think of that solution?

[JakeGinnivan]

Closing this issue. I think we understand the issue of wanting to use GitVersion in non-semver scenarios. #242 is tracking this