Gitversion: Always increment patch when merging to `master`?

Created on 8 Mar 2016 · 20Comments · Source: GitTools/GitVersion

Is there a way to set a configuration option to always increment patch? For our needs, we basically want to achieve something like MAJOR.MINOR.BuildMetadata, where the patch component is bumped automatically whenever we complete a pull request. Is there a way to do this?

Source

nshenoy

Most helpful comment

So I went through the code now and I found the source of the problem.
In NextVersionCalculator.cs it uses the method FindVersion.
In this it gets the baseversion and then it looks through all the intermediate commits and checks for the commit messages. Then instead of returning the new semantic version calculated from all the commit messages, let's say for example 5 times "+semver: patch" it only takes the maximum commit message and returns only the one which is the max. It seems this is so by design. What people expect to do is that it goes through all the commits and applies the increase of version one after each other and then returns the new semantic version.

Why is this important for us? We have a lot of packages which gets deployed and run through all our automation with the githubflow. This means we would need to tag each of the new commits, if we want to change them, which would let us end up with a ton of commits. Instead we would like to just increase our version based on all the commit messages with specific triggers like "+semver: patch" and let gitversion calculate the number for us. This is basically what I would expect from the documentation which says in continuous deployment which says the version is going to increment each commit. http://gitversion.readthedocs.io/en/latest/reference/continuous-deployment/ but instead it only updates the build metadata, which is not part of the version.

patrickwijerama on 4 May 2016

👍4

All 20 comments

You could use continuous integration mode, then use the gitversion variables directly to create your own version.

I am curious what the scenario is though?

JakeGinnivan on 9 Mar 2016

We're primarily using GitVersion to manage versioning of our Octopus deploy packages. So the argument on the team is that whenever a feature/ or hotfix/ branch is merged back into master then _most_ of the time the changes are not terribly significant will mostly be worthy of a patch increment. So tagging every PR feels like extra overhead. If there is something particularly meaty that is merged, then at that point the team may elect to bump the MINOR component via tagging. And if the change is significant then the MAJOR will be bumped via tagging. So MAJOR and MINOR are conscious decisions by the team. So if there was a way to have the PATCH just automatically increment on a completed pull request to master, then it would help significantly for deployments.

That being said, we can definitely cheat by using something like the VSTS autogenerated buildId as a patch and constructing a semver that way. But that can never reset to 0.

nshenoy on 10 Mar 2016

@nshenoy Setting mode to ContinuousDeployment in the configuration will give you this behaviour. Is there a reason why you can't use this mode or did you just not know about it? If you didn't know about it, what do you think can be done to improve the documentation (or anything else) to make it more visible and easily available?

asbjornu on 10 Mar 2016

@asbjornu Could you show an example of a ContinuousDeployment configuration that increments patch instead of PreReleaseNumber? I am having a lot of trouble getting patch to increment. After we sort that out the disconnect between the documentation and understanding will probably be made more clear.

aarondandy on 10 Mar 2016

When we set the mode to ContinuousDeployment, we end up getting a prerelease tag. True, the tag does increment with each commit, but it's still considered prerelease. For example, 1.0.1-ci.12 -> 1.0.1-ci.13. Instead, what I really want is 1.0.1 -> 1.0.2 etc.

nshenoy on 10 Mar 2016

What GitVersion variable are you using, then? As @JakeGinnivan mentioned, you most likely need to build the version number yourself based on the variables GitVersion generates. Are you using .exe or task?

asbjornu on 10 Mar 2016

I am using GitVersion.exe 3.4.1.0 from Chocolatey.

aarondandy on 10 Mar 2016

@aarondandy @nshenoy what, if any, configuration are you using within the GitVersionConfig.yaml file?

gep13 on 10 Mar 2016

Sorry for the delay, and thanks for responding. I have tried a few variations on the config but the attached is where I am currently. It only seems to increment CommitsSinceVersionSource from the tag but it is not incrementing patch even though I have selected "Patch" as the increment on master. I think my misunderstanding lies with this statement in the documentation: "increment: the part of the SemVer to increment _when GitVersion detects it needs to be_ (i.e commit after a tag)" . Are there other rules that determine when it increments? Is there a way to have it increment with each commit or would that be a totally new strategy implementation?

gitversion /showconfig
assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
tag-prefix: '[vV]'
continuous-delivery-fallback-tag: ci
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
legacy-semver-padding: 4
build-metadata-padding: 4
commits-since-version-source-padding: 4
commit-message-incrementing: Enabled
branches:
  master:
    mode: ContinuousDeployment
    tag:
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
  releases?[/-]:
    mode: ContinuousDeployment
    tag: beta
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
  features?[/-]:
    mode: ContinuousDeployment
    tag: useBranchName
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
  (pull|pull\-requests|pr)[/-]:
    mode: ContinuousDeployment
    tag: PullRequest
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    tag-number-pattern: '[/-](?<number>\d+)[-/]'
    track-merge-target: false
  hotfix(es)?[/-]:
    mode: ContinuousDeployment
    tag: beta
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
  support[/-]:
    mode: ContinuousDeployment
    tag:
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
  dev(elop)?(ment)?$:
    mode: ContinuousDeployment
    tag: unstable
    increment: Minor
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true

aarondandy on 10 Mar 2016

👍2

To be clear, the behavior I see is that after tagging a commit as 1.0.0 all future merge commits on master will have a version of 1.0.1 where what I expect to see is that commits would have a version similar to 1.0.{VersionSourcePatch + CommitsSinceVersionSource} .This way I can link each build to a specific commit without using pre-release identifiers as all of these builds are released to some environment.

aarondandy on 11 Mar 2016

I think I'm running into the same misunderstanding/confusion.

I've configured GitVersion to use mode: ContinuousDeployment, and thought that would mean on each commit from a tag I would get something like:

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1
- Commit 3 = 1.0.2
- Commit 4 = 1.0.3

Instead I'm seeing:

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1+1
- Commit 3 = 1.0.1+2
- Commit 4 = 1.0.1+3

I get that same behavior if I use mode: ContinuousDelivery:

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1+1
- Commit 3 = 1.0.1+2
- Commit 4 = 1.0.1+3

I've tried downgrading to GitVersion 3.0.0 and also saw the same behavior.

Hope that helps!

michaelnoonan on 23 Mar 2016

👍2

Seeing the same behavior. Patch is not incrementing on every commit to master.

seanamos on 9 Apr 2016

👍2

Same for me. Additionally in version 3.4.1 what I experienced was, when I added "+semver: minor" to a commit message it updated the minor version. When I tried the same with "+semver: patch" it does not increase the patch version neither on continuous delivery or deployment. In version 3.5.2 it seemed to not work anymore at all with commit messages.

patrickwijerama on 4 May 2016

👍4

any updates on this? I think I've ran into a related issue and opened https://github.com/GitTools/GitVersion/issues/889

Ashtonian on 2 Jun 2016

I think I understand why this happens now. Gitversion commit messages work based on the latest tag and will merge all commit increments and take the maximum out of them, based on the last tag. This happens, because gitversion assumes that every versioned package should become tagged in the source code as well. So if you use continuous delivery and version every build, then you should tag this builds as well in the source code, which then again will update the next commit version correctly.

patrickwijerama on 3 Jun 2016

Just to clarify I'm having problems getting GitVersion to auto increment the patch number without a pre-release tag on master. As is discussed in the first half of this ticket. My use case is for internal libraries - if the pull request gets approved , merged into master and it build - its "released" which doesn't break semver. Also for other use cases mainly octopus - it doesn't really make sense to do it any other way even if it goes against the ideology of semver. What if there was a compromise where we had a compliance setting or some override setting off by default that could be turned on to allow for this use case?

For Clarification - I'm expecting to see the following on master only:

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1
- Commit 3 = 1.0.2
- Commit 4 = 1.0.3

Instead I'm seeing:

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1+1
- Commit 3 = 1.0.1+2
- Commit 4 = 1.0.1+3

- Commit 1 = 1.0.0 (tagged 1.0.0)
- Commit 2 = 1.0.1-ci.2
- Commit 3 = 1.0.1-ci.3
- Commit 4 = 1.0.1-ci.4

and when I set continuous-delivery-fallback-tag: ci to '' it stops incrementing all together.

Ashtonian on 3 Jun 2016

We are pretty much in the same boat. We are of the philosophy that anything that is committed to 'master' is shipping. We ship by generating and publishing Nuget packages, which then leads to conflicts because the package version is being reused.

There is no need for us to explicitly tag the source code for every patch build. We would like to only have to tag when major/minor version is bumped. Also, we do not care if we skip patch numbers.

I agree that in Continuous Deployment mode I would expect the patch version to increase for each commit, and not use any prerelease tags.