> Also, breaking changes might not be found until after the commit is pushed.
That doesn't feel right. Conventional commits is related to semantic versioning. In that context, breaking changes refer to changes that break the backwards compatibility of the public interface of the software. Such a change forces the user to modify their own code/workflow. For example, a backwards incompatible change to the public API, major change to UI, file format change, etc.
These sorts of changes are deliberate and often carefully evaluated for the consequences they have for the user (a famous example is the Python 2 to 3 transition). If a breaking change is unexpected and identified only after a push, that is almost surely a bug that must not be published. Am I missing something here?
That doesn't feel right. Conventional commits is related to semantic versioning. In that context, breaking changes refer to changes that break the backwards compatibility of the public interface of the software. Such a change forces the user to modify their own code/workflow. For example, a backwards incompatible change to the public API, major change to UI, file format change, etc.
These sorts of changes are deliberate and often carefully evaluated for the consequences they have for the user (a famous example is the Python 2 to 3 transition). If a breaking change is unexpected and identified only after a push, that is almost surely a bug that must not be published. Am I missing something here?