[Feature] Prevent version increment of versions from tracked release branches

[rkieslinger]

I'm using a Release Flow branching strategy and I can almost configure GitVersion to do proper versioning for my scenario, except this one case:

• New branch release/v4.0 from main
• New commit on branch release/v4.0 (it gets SemVer set to 4.0.0-rc.1 -> nice!)
• New branch fix/bug from release/v4.0
• New commit on branch fix/bug (it gets SemVer set to 4.0.1-bug.1 -> WRONG - should be 4.0.0-bug.1!)
• New tag v4.0.0 on top commit of branch release/v4.0 (it gets SemVer set to 4.0.0 -> nice!)
• GitVersion on branch fix/bug now gets SemVer set to 4.0.1-bug.1 -> nice!

Here is my GitVersion.yml:

mode: ContinuousDeployment
commit-message-incrementing: Disabled
branches:
  master:
    increment: Minor
    tag: beta
    tracks-release-branches: true
    track-merge-target: true
    prevent-increment-of-merged-branch-version: false
  release:
    increment: Patch
    tag: rc
  fix:
    tag: useBranchName
    increment: Patch
    regex: ^fix(es)?[/-]
    source-branches:
    - release
    - fix
    tracks-release-branches: true
    pre-release-weight: 30000

Possible Implementation

It seems the BaseVersions resulting from TrackReleaseBranchesVersionStrategy always have shouldIncrement set to true. As there's already a configuration parameter called prevent-increment-of-merged-branch-version, is it possible to introduce a new parameter called prevent-increment-of-tracked-release-version which defaults to false and I could set to true on my configuration for branch type fix? I looked into the source code a bit and it seems, that this could be implemented relatively easy.

[HHobeck]

May I ask you what version your issue is related to? It seems to me that you have tested your scenario on the version 5.x which not reflecting the latest development initiatives. Better go with the main branch because we have done allot of work and changed the behavior e.g. how the branch configurations are determined.

Anyway in my opinion this is already solved (please use for your test release/v4.0.0 for now because of a known issue #3341).

Cheers.

[rkieslinger]

Yes, you are right. We are currently using 5.11.1 in production. I tested the behavior using 6.0.0-alpha.1, but it still gives me 4.0.1 on my fix/bug branch, where I would expect 4.0.0. It seems the behavior hasn't changed in my scenario using v6.

[HHobeck]

Hmm I see... you need to ensure that on your release and fix branch the option tracks-release-branches is set to false.

Try this configuration:

mode: ContinuousDeployment
commit-message-incrementing: Disabled
branches:
  main:
    increment: Minor
    label: 'beta'
    tracks-release-branches: true
    track-merge-target: true
    prevent-increment-of-merged-branch-version: false
  release:
    increment: Patch
    label: 'rc'
  fix:
    label: '{BranchName}'
    increment: Inherit
    regex: ^fix(es)?[/-]
    source-branches:
    - release
    - fix

BTW: You can also use the feature or hotfix branch instead of defining your own fix branch.

[github-actions]

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.

[github-actions]

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.