-
|
I am using azure classic build pipeline with the gitVersion/setup and gitVersion/execute task. Here is my gitVersion config:
GitVersion is behaving as expected producing the propriate versions as specified by the config. However, when I try to do a patch-version-bump-message, nothing happens in the develop branch by adding the bump message in the PR and GitVersion just increases the commits on the prepatch tag. For instance if the previous version was 1.4.0-dev.3 and then I created a branch from develop, made some changes, commit, push and create a PR. In the PR I added +semver: patch and then approved the PR. GitVersion calculates the next version to be 1.4.0-dev.4. I outputted the git log for the last few commits: commit bf180405399e5dd7fe010c2b45c6971efec68f76 I am assuming I am doing something wrong, or the config is wrong, or my expectation is wrong. How would I manually bump the version using Visual Studio / Azure Devops PR workflow (without going to the git cmd/bash)? Here is the logs from the gitVersion task:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The bump message feature like it is implemented in the actual version of git-version is there to bump the increment to a higher value for the calculation of the next version. If lets say the base version is 1.0.0 then the following matrix applies: A commit without a bump message yields:
A commit with semver+: patch message yields
A commit with semver+: minor message yields
A commit with semver+: major message yields
You need to think about the use case of using the bump message feature. The motivation is more dependent on what changes your commit includes from the development perspective. When you in the role of a developer don't care about what the target branch might be and think: "Oh it's not just a minor change it’s a huge change which should yield to a major version increment because I have updated the API with a breaking change." |
Beta Was this translation helpful? Give feedback.
-
|
From your reply...
What I understand from your reply, is that if a branch is configured for an increment (PATCH, MINOR, or MAJOR), the bump message doesn't override the increment configuration for the given branch. For my example, using the config I provided, the develop branch is configured 'MINOR' increments (increment: Minor). So even though, in the commit message I put +semver: patch. That will never happen. I was assuming that the bump message gave the user the ability to override the increment configuration for that branch. So in my example, I was expecting 1.4.1-dev but because the develop branch increment is configure for MINOR, it's ignoring the message bump? |
Beta Was this translation helpful? Give feedback.
-
Actually to be precise the algorithm consolidates the increments and uses the highest one. In your case the increment of the branch is higher than the one in the bump message. |
Beta Was this translation helpful? Give feedback.
The bump message feature like it is implemented in the actual version of git-version is there to bump the increment to a higher value for the calculation of the next version. If lets say the base version is 1.0.0 then the following matrix applies:
A commit without a bump message yields:
A commit with semver+: patch message yields
A commit with semver+: minor message yields