[GH-ISSUE #117] Set update-major to "breaking" by default? #2

Closed
opened 2026-03-04 00:40:41 +03:00 by kerem · 2 comments
Owner

Originally created by @pat-s on GitHub (Oct 18, 2024).
Original GitHub issue: https://github.com/thegeeklab/git-sv/issues/117

Wondering why the default is empty but at the same time there is a release-section that processes breaking changes by also hasn't any commit-type assigned?

Originally created by @pat-s on GitHub (Oct 18, 2024). Original GitHub issue: https://github.com/thegeeklab/git-sv/issues/117 Wondering why the default is empty but at the same time there is a release-section that processes breaking changes by also hasn't any `commit-type` assigned?
kerem closed this issue 2026-03-04 00:40:42 +03:00
Author
Owner

@xoxys commented on GitHub (Oct 20, 2024):

Breaking changes are detected by two mechanisms:

  • BREAKING CHANGE string in commit message body
  • commit subject with ! suffix, e.g. feat!

Major version bumps are always performed if the history contains any breaking changes detected by one of the mechanisms described above. The versioning.update-major config option is intended to bump major versions on other commit types, e.g. versioning.update-major: [refactor] to bump the major version also on all refactor commits.

What you are asking for is a default configuration to tread commit messages like breaking: this commit breaks everything as a breaking change by default?

<!-- gh-comment-id:2424861401 --> @xoxys commented on GitHub (Oct 20, 2024): Breaking changes are detected by two mechanisms: - `BREAKING CHANGE` string in commit message body - commit subject with `!` suffix, e.g. `feat!` Major version bumps are always performed if the history contains any breaking changes detected by one of the mechanisms described above. The `versioning.update-major` config option is intended to bump major versions on other commit types, e.g. `versioning.update-major: [refactor]` to bump the major version also on all refactor commits. What you are asking for is a default configuration to tread commit messages like `breaking: this commit breaks everything` as a breaking change by default?
Author
Owner

@pat-s commented on GitHub (Oct 21, 2024):

Ah yes, my bad. Fully compliant with conv commits (sorry, never had to use a breaking commit so far since applying conv commits). Intuitively I thought about the breaking: prefix but I see that not having that prefix defined is more accurate.

What you are asking for is a default configuration to tread commit messages like breaking: this commit breaks everything as a breaking change by default?

Yes but users can do so anyway in their config then. I guess sticking with conv commit defaults is the best approach.

<!-- gh-comment-id:2427284274 --> @pat-s commented on GitHub (Oct 21, 2024): Ah yes, my bad. Fully compliant with conv commits (sorry, never had to use a breaking commit so far since applying conv commits). Intuitively I thought about the `breaking:` prefix but I see that not having that prefix defined is more accurate. > What you are asking for is a default configuration to tread commit messages like breaking: this commit breaks everything as a breaking change by default? Yes but users can do so anyway in their config then. I guess sticking with conv commit defaults is the best approach.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/git-sv#2
No description provided.