BREAKING CHANGE: You no longer have to use alertTitle and children to display your alert content. Use children only instead. This is because we found out that people actually display the "content" of the alert in alertTitle and not in both alertTitle and children (description). Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
I want the diff to also be added when creating release notes but it only adds whatever is added right after the BREAKING CHANGE: keyword.
Originally created by @rodoabad on GitHub (Nov 10, 2020).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/313
I have this example.
---
BREAKING CHANGE: You no longer have to use `alertTitle` and `children` to display your alert content. Use `children` only instead. This is because we found out that people actually display the "content" of the alert in `alertTitle` and not in both `alertTitle` and `children` (description). Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
```diff
-<InlineCriticalAlert alertTitle='ALERT SUMMARY'/>
+<InlineCriticalAlert>
+ ALERT SUMMARY
+</InlineCriticalAlert>
```
---
I want the diff to also be added when creating release notes but it only adds whatever is added right after the `BREAKING CHANGE: ` keyword.
feat: add new feature
Description of the new feature
more details
even more details
BREAKING CHANGE: You no longer have to use alertTitle and children to display your alert content.
Use children only instead. This is because we found out that people actually display the "content" of the alert in alertTitle and not in both alertTitle and children (description).
Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
feat: add new feature
Description of the new feature
more details
even more details
BREAKING CHANGE: You no longer have to use alertTitle and children to display your alert content.
Use children only instead. This is because we found out that people actually display the "content" of the alert in alertTitle and not in both alertTitle and children (description).
Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
<!-- gh-comment-id:725630801 -->
@djgilcrease commented on GitHub (Nov 11, 2020):
This very much depends on the parser you are using and not the spec itself, so you should likely file an issue on the parser/tool you are using.
I have a golang parser which I added this example as a test case to so that it will support
`No Extra Line Breaks after the BREAKING CHANGE`
https://gitlab.com/digitalxero/go-conventional-commit/-/blob/master/conventional_commits_test.go#L228
```
feat: add new feature
Description of the new feature
more details
even more details
BREAKING CHANGE: You no longer have to use alertTitle and children to display your alert content.
Use children only instead. This is because we found out that people actually display the "content" of the alert in alertTitle and not in both alertTitle and children (description).
Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
```
`Extra Line Breaks after the BREAKING CHANGE`
https://gitlab.com/digitalxero/go-conventional-commit/-/blob/master/conventional_commits_test.go#L258
```
feat: add new feature
Description of the new feature
more details
even more details
BREAKING CHANGE: You no longer have to use alertTitle and children to display your alert content.
Use children only instead. This is because we found out that people actually display the "content" of the alert in alertTitle and not in both alertTitle and children (description).
Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.
```
The specification sounds more like BREAKING CHANGE is a special footer:
If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
So in that case it would behave the same as every other footer, newline + footer identifier to separate them.
<!-- gh-comment-id:771659586 -->
@mainrs commented on GitHub (Feb 2, 2021):
The specification sounds more like `BREAKING CHANGE` is a special footer:
> If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
So in that case it would behave the same as every other footer, newline + footer identifier to separate them.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @rodoabad on GitHub (Nov 10, 2020).
Original GitHub issue: https://github.com/conventional-commits/conventionalcommits.org/issues/313
I have this example.
BREAKING CHANGE: You no longer have to use
alertTitleandchildrento display your alert content. Usechildrenonly instead. This is because we found out that people actually display the "content" of the alert inalertTitleand not in bothalertTitleandchildren(description). Because of that, we're consolidating both. This also opens up opportunities to have other components used within an alert component like an accordion for Progressive Disclosure design patterns.I want the diff to also be added when creating release notes but it only adds whatever is added right after the
BREAKING CHANGE:keyword.@djgilcrease commented on GitHub (Nov 11, 2020):
This very much depends on the parser you are using and not the spec itself, so you should likely file an issue on the parser/tool you are using.
I have a golang parser which I added this example as a test case to so that it will support
No Extra Line Breaks after the BREAKING CHANGEhttps://gitlab.com/digitalxero/go-conventional-commit/-/blob/master/conventional_commits_test.go#L228
Extra Line Breaks after the BREAKING CHANGEhttps://gitlab.com/digitalxero/go-conventional-commit/-/blob/master/conventional_commits_test.go#L258
@mainrs commented on GitHub (Feb 2, 2021):
The specification sounds more like
BREAKING CHANGEis a special footer:So in that case it would behave the same as every other footer, newline + footer identifier to separate them.