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

[HHobeck]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool

GitVersion version

6.0.1

Operating system

Windows

What are you seeing?

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

This feature was inspired from the following discussion:

• How to correctly migrate from V5 Mainline mode to V6 Mainline versioning without changes in behaviour? #4143

We need a new bump message format to suppress the version increment of a version calculation run. I think e.g. =semver: none|minor|major|patch bump message should be used as a default format for the following workflows:

• GitFlow/v1
• GitHubFlow/v1
• TrunkBased/preview1

What is expected?

If you specify =semver: none the increment value of the e.g. branch configuration will be overruled.

Steps to Reproduce

Using the configuration:

workflow: TrunkBased/preview1
branches:
  main:
    mode: ContinuousDelivery
    increment: Patch

USE CASE 1:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two =semver: none'
• 'message three =semver: none'

should yield to:
1.0.0-3

USE CASE 2:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one +semver: minor'
• 'message two =semver: none'
• 'message three =semver: none'

should yield to:
1.1.0-3

USE CASE 3:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two +semver: minor'
• 'message three =semver: none'

should yield to:
1.1.0-2

USE CASE 4:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two =semver: none'
• 'message three +semver: minor'

should yield to:
1.1.0-1

Using the configuration:

workflow: GitFlow/v1
branches:
  main:
    mode: ContinuousDelivery
    increment: Patch

USE CASE 5:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two =semver: none'
• 'message three =semver: none'

should yield to:
1.0.0-3

USE CASE 6:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one +semver: minor'
• 'message two =semver: none'
• 'message three =semver: none'

should yield to:
1.0.0-3

USE CASE 7:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two +semver: minor'
• 'message three =semver: none'

should yield to:
1.0.0-3

USE CASE 8:
with the following commits on main:

• 'a commit with a tag' (tag: 1.0.0)
• 'message one =semver: none'
• 'message two =semver: none'
• 'message three +semver: minor'

should yield to:
1.1.0-3

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

No response

[Jaykul]

This already exists, but In the configuration the default requires the +semver:none or +semver:skip because of the configuration:

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)'

I always tell people to remove the + from the front, and require it to be on a new line, to make the message a valid git trailer:

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)'

But in any case, it does suppress the version increment...

[HHobeck]

Hi Joel,

Thank you for your comment. In the previous version of git version it was possible to suppress/overrule the increment by defining bump messages when using the Mainline mode. This behavior has been changed in version 6.0.0 with the new Mainline version strategy. Now all workflows are behaving the same regarding how the bump message are interpreted.

Regards
Hardy

[Jaykul]

After some testing, I think I see what the problem is. In the latest versions, you can only increase the bump (e.g. from "None" to "Patch", "Minor" or "Breaking") but you can't decrease the bump (e.g. from "Patch" to "None").

It's treating the configured "Increment" as a minimum, instead of as a default.

I think this is a bug. My teams can't use this with that change, because it will essentially require us to switch to default of "None" and always set the version in the commit -- instead of using the default of "Patch" and only needing to set the version when we add a feature or when we don't want to increment at all (because it's just typo fixing in the documentation).