Reputation: 189
We are following trunk based development approach, where when a feature is ready, we merge it to master and create release branch with semantic version, so we have full control on major/minor/patch versioning,
eg :
release/1.0.0 .
release/1.0.1 etc ..
We run gitversion on our build step which is considering versioning provided in branch name and creating version based on it (default gitversion behavior), and we propagate to our lower systems We tag this version only once it got successfully deployed to production (last stage in our ci/cd workflow)
The issue I am seeing right now is when cherry picking bug fixes and merging to release branch which is not tagged yet. (typical trunk based approach)
the behaviour I was looking for is as follows:
assume release/1.0.0 (current tagged release branch) ,gitversion - appname-1.0.0-rc.1 .
After a bug fix merged to master
- cherry-pick bug fix commits from master , merge to release/1.0.0
- gitversion bump patch value to appname-1.0.0-rc.2
- new commit on release/1.0.0 branch
- gitversion bump patch value to appname-1.0.0-rc.3
Instead, I am seeing the following behaviour:
- cherry-pick bug fix commits from master , merge to release/1.0.0
- gitversion doesn't increment patch value, semantic version stays at appname-1.0.0-rc.1
- new commit on release/1.0.0 branch
- semantic version stays at appname-1.0.0-rc.1
Here are the configs I m using GitVersion.txt
Upvotes: 2
Views: 1262
Reputation: 4234
GitVersion has a hierarchy it uses for determining the calculated version, all defined by the various default branch configurations, which can be seen by executing GitVersion /showConfiguration
.
It seems like you need to customize your configuration based on your team's workflow and branching model in order to achieve the desired behavior.
Upvotes: -1