feat: support version bump reset messages - #5123
Conversation
8aa4108 to
c2c96fb
Compare
c2c96fb to
09cd27c
Compare
|
@fzlzjerry please rebase your branch onto |
|
hey @HHobeck mind to have a look? |
09cd27c to
ac9717d
Compare
|
@arturcic Rebased onto current |
ac9717d to
287cfc5
Compare
HHobeck
left a comment
HHobeck
left a comment
There was a problem hiding this comment.
Thank you for your work on this! I’ve left a few comments for your consideration.
fzlzjerry
changed the title
|
The new CI run is green except for |
|
@HHobeck I reworked this around the reset/baseline model in 97edd62 and replied to all four review threads. |
please rebase on main again - it should be fixed |
97edd62 to
8d87db3
Compare
|
@HHobeck I addressed all seven follow-up threads in |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 31 out of 31 changed files in this pull request and generated no new comments.
Suppressed comments (1)
docs/input/docs/reference/version-increments.md:69
- Inline code span is split across a newline (
`=semver:on one line andpatchon the next), which can render incorrectly in Markdown. Keep each=semver: …example on a single line.
The configured branch increment acts as the minimum for these `+semver`
messages. To reset that baseline instead, use `=semver: none`, `=semver:
patch`, `=semver: minor`, or `=semver: major`. This is useful, for example,
HHobeck
left a comment
HHobeck
left a comment
There was a problem hiding this comment.
Okay looks quite good. Good work. If you fix the last three open comments I will approve it.
|
|
Queued — the merge queue status continues in this comment ↓. |
Merge Queue Status
This pull request spent 19 seconds in the queue, including 2 seconds running CI. Required conditions to merge
|
|
Thank you @fzlzjerry for your contribution! |
Description
Add a configurable
version-bump-reset-messagepattern with the default=semver:for the GitFlow, GitHubFlow, and TrunkBased workflows.The default major, minor, patch, and no-bump patterns now accept either
+semveror
=semver. Those existing patterns select the increment value; a matchingreset message discards increments accumulated before that commit and suppresses
the configured branch increment. The existing
+semverminimum-incrementbehavior is unchanged.
Reset detection is centralized in
IncrementStrategyFinderand exposed throughCommitMessageIncrement. Range-based strategies scan from the newest commit,consolidate newer bump messages, and stop at the first reset. Mainline clears its
accumulated increment at the reset commit and keeps the branch increment
suppressed until the current mainline segment ends.
This also updates effective configuration output, CLI overrides, the 7.0 schema,
workflow snapshots, and the configuration and version-increment documentation.
Related Issue
Resolves #4144
Motivation and Context
Regular
+semvermessages treat the configured branch increment as a minimum,so they cannot lower a Patch branch to None for documentation-only changes. The
new
=semverreset form can suppress that branch increment without changing thebehavior of existing
+semvermessages.How Has This Been Tested?
dotnet test ./src/GitVersion.Core.Tests/GitVersion.Core.Tests.csproj --no-restore(36,211 passed)
dotnet test ./src/GitVersion.Configuration.Tests/GitVersion.Configuration.Tests.csproj --no-restore(100 passed)
dotnet test ./src/GitVersion.App.Tests/GitVersion.App.Tests.csproj --no-restore(356 passed)
dotnet format ./src/GitVersion.slnx --verify-no-changes --no-restoregit diff --checkThe Core integration coverage includes all eight acceptance scenarios from the
issue, all four reset values across the three built-in workflows, a custom reset
pattern, disabled commit-message incrementing, the requested merged-branch
regression, newest-first traversal stopping at the most recent reset, and a
malformed reset marker without a valid increment (32 focused cases).
Screenshots (if appropriate):
Not applicable.
Checklist: