[PR #152] [MERGED] docs: update ! to better reflect how it is used in the wild #321

New Issue

GiteaMirror · 2026-02-17T11:58:56-06:00

GiteaMirror commented

2026-02-17 11:58:56 -06:00

📋 Pull Request Information

Original PR: https://github.com/conventional-commits/conventionalcommits.org/pull/152
Author: @bcoe
Created: 5/19/2019
Status: ✅ Merged
Merged: 5/26/2019
Merged by: @bcoe

Base: master ← Head: better-breaking

📝 Commits (1)

66ec9ac docs: update ! to better reflect how it is used in the wild

📊 Changes

1 file changed (+13 additions, -6 deletions)

View changed files

📝 content/next/index.md (+13 -6)

📄 Description

Now that I've had some experience using ! in the wild, my opinion of how we should define the feature has changed a bit.

There are two incidents on my mind:

myself and my peers released a breaking change as a minor because we accidentally didn't rewrite the merge message (dropping the BREAKING CHANGE that we had in the description); this is currently fairly easy to do with GitHub's UI.
motivated by the above incident, we started using ! in our commit messages -- however, history repeated itself and we merged a commit with ! in the header, but no BREAKING CHANGE in body.

In the process of these two incidents, I came around to @DominicKramer and @ofrobots' argument that having an indicator of a breaking change in the header of the commit message itself should be enough to represent a breaking change -- it would have saved us from both accidents.

Long story short:

I'd like to advocate that we fallback to the description of the commit message as a description of a breaking change, if no BREAKING CHANGE is provided in the body or footer; this makes it so that ! can be used as an alternative to BRAKING CHANGE.

I'd also like to advocate that we consider moving to version 1.0.0 of the specification (CC: @damianopetrungaro). I'm feeling like we've had a great chance to play with the specification in a variety of production environments and it has reached a healthy point of maturity.

CC: @JustinBeckwith, @zeke, @apetro,

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/conventional-commits/conventionalcommits.org/pull/152 **Author:** [@bcoe](https://github.com/bcoe) **Created:** 5/19/2019 **Status:** ✅ Merged **Merged:** 5/26/2019 **Merged by:** [@bcoe](https://github.com/bcoe) **Base:** `master` ← **Head:** `better-breaking` --- ### 📝 Commits (1) - [`66ec9ac`](https://github.com/conventional-commits/conventionalcommits.org/commit/66ec9ac3e0cb3a39f6b547cfb4656b3ac235dad7) docs: update ! to better reflect how it is used in the wild ### 📊 Changes **1 file changed** (+13 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `content/next/index.md` (+13 -6) </details> ### 📄 Description Now that I've had some experience using `!` in the wild, my opinion of how we should define the feature has changed a bit. There are two incidents on my mind: 1. myself and my peers released a breaking change as a minor because we accidentally didn't rewrite the merge message (dropping the BREAKING CHANGE that we had in the description); this is currently fairly easy to do with GitHub's UI. 1. motivated by the above incident, we started using `!` in our commit messages -- however, history repeated itself and we merged a commit with `!` in the header, but no BREAKING CHANGE in body. In the process of these two incidents, I came around to @DominicKramer and @ofrobots' argument that having an indicator of a breaking change in the header of the commit message itself should be enough to represent a breaking change -- it would have saved us from both accidents. Long story short: I'd like to advocate that we fallback to the description of the commit message as a description of a breaking change, if no BREAKING CHANGE is provided in the body or footer; this makes it so that `!` can be used as an alternative to BRAKING CHANGE. I'd also like to advocate that we consider moving to version 1.0.0 of the specification (CC: @damianopetrungaro). I'm feeling like we've had a great chance to play with the specification in a variety of production environments and it has reached a healthy point of maturity. CC: @JustinBeckwith, @zeke, @apetro, --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-02-17 11:58:56 -06:00

GiteaMirror closed this issue

2026-02-17 11:58:57 -06:00

GiteaMirror referenced this issue

2026-02-17 12:03:30 -06:00

[PR #321] [MERGED] docs: correct typo #437

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#321