[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).

[HHobeck]

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

I'm confused how you came up to the conclusion that this is a bug. In the comment I posted before I explained that this was a design decision and the behavior is correct in version 6. The feature #4144 is exactly the missing puzzle to get back this behavior.

[Jaykul]

Sorry, but precisely for the reason I stated -- it seemed to me that it's still possible to overrule the increment with bump messages, but only to increase the "increment" from whatever the default is, but not to decrease it from the default. I don't understand making the "increment" into a "minimum increment" instead of a "default increment" ...

But if that is the new intended behavior, that's fine. I encourage you to document it as a minimum in the configuration docs.

I mean, it still makes this a version we can't use, since it completely breaks our use cases, but obviously we can try to upgrade again if this feature gets implemented. In the meantime, we're still okay with 5.x, for now.