Gitversion: Is it possible to configure GitVersion for Release Flow?

[marius-stanescu-archive360]

I am trying to configure GitVersion to work with the Release Flow branching strategy.

Basically, I have a mainline Master branch, Release, Feature and Fix branches. The Feature and Fix branches are created from the Master branch and merged back into Master via a pull request. At the end of a sprint, I create a Release branch from Master, which will last till the end of the next sprint, when a new Release branch will be created. The Release branches are not merged back into master. They can even be deleted after a new Release branch has been created. If there's a hotfix needed, it will be developed on a Fix branch created from and merged back into master and then cherry-picked into the current Release branch. I only use git tags for major releases.

Going back to GitVersion, I want to configure it so that the minor version number will increase when I create a new release branch and the patch number to increase when there's a new commit on the release branch (cherry-picked from a Fix branch).

Is this possible? How?

I also asked the question on stack overflow.

[stoopered]

Same question I asked yesterday. Ignore Tags on Release Branches #1576

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[alarobric]

I'd be interested in this too. Trying to find a solution to handle versioning on Azure DevOps when we use a strategy similar to ReleaseFlow.
Exactly as marius said: I want to configure it so that the minor version number will increase when I create a new release branch (i.e. master is always last release major.minor + 1, with increasing patch number for each commit to master or release.

[underscoreHao]

@marius-stanescu @alarobric I can provide a working solution for everything up until incrementing the patch automatically when you do a fix on the release branch - I solve that by tagging. I can't get the patch increment to work in any capacity if the cherry picked branch is created from master :(

[underscoreHao]

The GitVersion.yml file for my working setup

mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
branches:
  master:
    mode: ContinuousDeployment
    tag: '-dev'
    increment: Minor
    track-merge-target: true
    tracks-release-branches: true
    is-release-branch: false
    prevent-increment-of-merged-branch-version: false
  release:
    regex: release?[/]
    mode: ContinuousDeployment
    increment: Patch # not working, when merging a bugfix from master
    tag: ''
    is-release-branch: true
    prevent-increment-of-merged-branch-version: true
  feature:
    regex: feature?[/]
    mode: ContinuousDeployment
    increment: Inherit
    tag: '-alpha'
    is-release-branch: false
    prevent-increment-of-merged-branch-version: true
  bugfix:
    regex: bugfix?[/]
    mode: ContinuousDeployment
    increment: Inherit
    tag: '-bugfix'
    is-release-branch: false
    prevent-increment-of-merged-branch-version: true
    source-branches: ['master', 'feature', 'release']
  pull-request:
    mode: ContinuousDeployment
    tag: '-pr'
ignore:
  sha: []

If anyone manages to make ReleaseFlow working fully please ping me!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[asbjornu]

There's no explicit support for release flow in GitVersion, but I suppose it can be configured. The Stack Overflow question has an accepted answer, is that a working solution for everyone?

[Stevoni]

As someone attempting to implement Release Flow with GitVersion in Azure DevOps, the accepted answer is not suitable for me since it's primarily geared toward TeamCity and not as flexible as GitVersion.

From what I can tell the limitation for Mainline is incrementing on the wrong branch.

The main branch is master, but the release branch is special (in my mind) in that it should increment the minor on the initial commit and the patch on the subsequent commits. I think hotfix can be designated a release branch and increment patch on each commit so long it's built from release.

I don't think I'm attempting to use GitVersion wrong, but here's the process flow I was thinking:

1. Master is on M[ajor].m[inor].p[atch]-ci.[prerelease number] (1.0.0-ci.0)
2. A feature branch is created, work is done, pull request approved an merged into master using squash (because the others (merge no-ff, rebase, and semi-linear) seem to increment too many times and not just counting the merge commit)
3. The build is started on master to be deployed to the lowest environment with version 1.0.0-ci.1
4. The cycle repeats n times until a release is ready
5. The release branch is created with master 1.0.0-ci.5 as the base and a build is started. I would assume the build number should become 1.1.0.
6. A fix is created in the pre-production environment and the release branch would increment to 1.1.1.
7. The code is deployed as 1.1.1.
8. A hotfix is created with the release branch 1.1.1 as the base and the deployed build would become 1.1.2.
9. Merging the hotfix into the release branch and the release branch into master would move the master build to 1.1.2-ci.[number of commits since 1.0.0-ci.5 was "promoted" to 1.1.0].
10. The feature branch merging back into master would then build as 1.1.2-ci.2 being the second commit since 1.0.0-ci.5.

That said, I may be confused because it's pretty late for me but that seems to be the process for release flow.

This may be a bug or my misunderstanding of the configuration but the release branch appears to be incrementing twice: one for the merge commit and another for the current branch.

Merge commit b1bdb incremented base versions Minor, now 1.1.0
0 commits found between b1bdb and b1bdb
Performing Minor increment for current branch
Which outputs 1.2.0

And when I set it to not increment, it's not incrementing any value:

Merge commit b1bdb incremented base versions None, now 1.0.0
0 commits found between b1bdb and b1bdb
Performing None increment for current branch
Which outputs 1.0.0

As mentioned above, I would think it would increment because Master (although it's just incrementing the pre-release number) being the mainline had incremented independently of the release branch.

[Stevoni]

Has anyone figured out the best way to implement this for other deployment systems, like Azure DevOps?

[stoopered]

If GitVersion would just add functionality to count commits on the branch, and use release name as the base, this could be simple.
(for speed it would default to false so it doesnt run on branches like master) basically it would perform a (git rev-list --count HEAD ^) on the release branch and count commits, and use that as the Patch version.

Or even better, allow different ways of versioning on different branches, like Master would be specified to Major.Minor.Patch, and Release could be Major.Minor.CommitsSinceBranchCreated

If for example, you create a release branch as

GitVersion Yaml:
branches:
releases:
CommitsSinceBranchCreationAsPatch: true

Release Branch examples
releases/release-1.0
First commit 1.0.1
Second Commit 1.0.2

releases/release-1.0.5
First Commit 1.0.6
Second Commit 1.0.7

[asbjornu]

@stoopered, branch names aren't a stable source of version information, since they are deleted – usually right after they are merged.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.