Does GitVersion 6 still support the logic to step minor on feature/XX and path on bugfix/xx branches?

[CJCombrink]

This is very much related to this feature: #1221
The last screenshot in that discussion is almost exactly what I want

My current config is rather basic, using GitHubFlow/v1 and ContinuousDeployment on my main branch.
I want increment to be based on the last branch that was merged, so that feature/xx branches step the minor and bugfix/xx step the patch.
I also want to control this using the messages if possible (probably for major versions)

I tried searching the net but can only find answers for GitVersion < 6

This is my current configuration

workflow: GitHubFlow/v1
tag-prefix: ''
version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
semantic-version-format: Strict
branches:
  main:
    mode: ContinuousDeployment
    increment: Minor
    prevent-increment:
      when-current-commit-tagged: true
    regex: ^development$
    is-release-branch: true
  release:
    mode: ContinuousDeployment
    prevent-increment:
      when-current-commit-tagged: true
    track-merge-message: true
    is-release-branch: true
  feature:
    mode: ContinuousDelivery
    label: alpha
    regex: ^feature/(?<BranchName>.+)
  pull-request:
    mode: ContinuousDelivery
    label: pre
    regex: ^PR-
mode: ContinuousDeployment
is-main-branch: true

The issue with increment: Minor in main is that I can never use a message to just step the patch due to the logic discussed here
And setting it to Increment: Patch would require that one almost always ad the +semver: minor to commit messages, defeating the use of GitVersion since we need patches very seldom, and we already use the branch names to differentiate.

Any help will be appreciated

[HHobeck]

Hi there.

Can you please allaborate what you are trying to achieve? In version 6 the unit test with the name MergeFeatureIntoMainlineWithMinorIncrementAndThenMergeHotfix is still existing and is green:

https://github.com/GitTools/GitVersion/blob/main/src/GitVersion.Core.Tests/VersionCalculation/NextVersionCalculatorTests.cs#L184

Edit:

Have you seen the following feature issue?

• [FEATURE]: Support of '=semver: none|minor|major|patch' bump message to suppress the version increment #4144

[CJCombrink]

@HHobeck Thanks for the response and links, I will do some reading.

Just a question on this: Yes I want the exact behaviour of that unit test, am I correct in assuming (from the test) that I should change from GitHubFlow/v1 (current) to TrunkBased/preview1 for this to work? Or is the expectation that it should work?

I have no real reason to stick with GitHubFlow if TrunkBased will achieve what I need.

One thing I can comment between our workflow and the test is that we do not tag on feature or bugfix branches, only on the development branch. I don't think this should make a difference but can be wrong.

[HHobeck]

The branch configuration with name track-merge-message can be used to control the behavior whether or not the merge message will be evaluated. If I'm not wrong the mechanism you are referring only applies in the Mainline version strategy which is part of the TrunkBased/preview1 workflow.

I don't see any reason why not implementing it in the MergeMessage version strategy as well:

Please notice that the Mainline version strategy can be seen as a single version strategy which might be not compatible with others.

Cheers.