feat: reduce ambiguity around footer/body #185
Conversation
Co-Authored-By: Zeke Sikelianos <zeke@sikelianos.com>
|
@bcoe apart from the comment I left I do really like the work! |
Co-Authored-By: Damiano Petrungaro <damianopetrungaro@gmail.com>
| @@ -21,7 +21,7 @@ The commit message should be structured as follows: | |||
|
|
|||
| [optional body] | |||
|
|
|||
| [optional footer] | |||
| [optional footer(s)] | |||
There was a problem hiding this comment.
not agree. technically, there's one footer with probably multiple sections. but anyway.
| A BREAKING CHANGE can be part of commits of any _type_. | ||
| 1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. | ||
| 1. _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others. | ||
| 1. _footers_ other than `BREAKING CHANGE: <description>` may be be provided and and follow a convention similar to |
There was a problem hiding this comment.
double "be" and double "and". ;)
| 1. Breaking changes MUST be indicated in the type/scope prefix of a commit, or at the beginning of its optional body or footer section. | ||
| 1. If included in the body or footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., | ||
| 1. A commit body is free-form and MAY consist of any number of newline separated paragraphs. | ||
| 1. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of |
There was a problem hiding this comment.
I don't think and don't like to promote that as multiple footers. Better, in my mind, is to promote it as footer containing multiple sections (git trailers)
| 1. The units of information that make up conventional commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase. | ||
| 1. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer. |
There was a problem hiding this comment.
hm, so the trailer is BREAKING-CHANGE: <description>? And without the hyphen won't be valid anymore? Maybe adding and example as next sentence would be great.
There was a problem hiding this comment.
No I think we should support both approaches, since it's confusing to not support breaking-change, since it's closer to other footers.
There was a problem hiding this comment.
Yea. So the BREAKING CHANGE: will still be supported too?
|
I'm noticing that this change resulted in the removal of the |
Working from @JeanMertz's suggestions in #179 proposes a few new rules related to differentiating between footer and body sections of commit message.
Builds on top of git trailers and RFC822 folding conventions.
(I also did some minor editing, and removed some text I felt was redundant, given that the spec is growing a little bit).
fixes: #170
CC: @epage, @JeanMertz, @blowmage