…ventional/`

Remove the code that writes out the rest of the commit message from the defaulttemplate.BREAKING CHANGE: The default Markdown changelog template and release notes templatewill no longer print out the entire commit message contents, instead, it will onlyprint the commit subject line. This comes to meet the high demand of better formattedchangelogs and requests for subject line only. Originally, it was a decision to nothide commit subjects that were included in the commit body via the `git merge --squash`command and PSR did not have another alternative.  At this point, all the built-inparsers have the ability to parse squashed commits and separate them out into theirown entry on the changelog. Therefore, the default template no longer needs to writeout the full commit body. See the commit parser options if you want to enable/disableparsing squash commits.Resolves:python-semantic-release#733

…tructuredText templateRemove the code that writes out the rest of the commit message from the defaulttemplate.BREAKING CHANGE: The default ReStructured changelog templatewill no longer print out the entire commit message contents, instead, it will onlyprint the commit subject line. This comes to meet the high demand of better formattedchangelogs and requests for subject line only. Originally, it was a decision to nothide commit subjects that were included in the commit body via the `git merge --squash`command and PSR did not have another alternative.  At this point, all the built-inparsers have the ability to parse squashed commits and separate them out into theirown entry on the changelog. Therefore, the default template no longer needs to writeout the full commit body. See the commit parser options if you want to enable/disableparsing squash commits.Resolves:python-semantic-release#733

…e deprecating angular parser

…cating angular parser

…escriptionsBREAKING CHANGE: Any issue resolution footers that the parser detects will nowbe removed from the `commit.descriptions[]` list. Previously, the descriptions includedall text from the commit message but now that the parser pulls out the issue numbersthe numbers will be included in the `commit.linked_issues` tuple for user extraction inany changelog generation.

…ionsBREAKING CHANGE: Any issue resolution footers that the parser detects will nowbe removed from the commit.descriptions[] list. Previously, the descriptions includedall text from the commit message but now that the parser pulls out the issue numbersthe numbers will be included in the commit.linked_issues tuple for user extraction inany changelog generation.

…ionsBREAKING CHANGE: Any issue resolution footers that the parser detects will nowbe removed from the `commit.descriptions[]` list. Previously, the descriptions includedall text from the commit message but now that the parser pulls out the issue numbersthe numbers will be included in the `commit.linked_issues` tuple for user extraction inany changelog generation.

…m commit descriptionsBREAKING CHANGE: Any breaking change footer messages that the conventional commit parserdetects will now be removed from the `commit.descriptions[]` list but maintained in and onlyin the `commit.breaking_descriptions[]` list. Previously, the descriptions includedall text from the commit message but that was redundant as the default changelog nowhandles breaking change footers in its own section.

… commit descriptionsBREAKING CHANGE: Any release notice footer messages that the commit parser detects willnow be removed from the `commit.descriptions[]` list but maintained in and only in the`commit.notices[]` list. Previously, the descriptions included all text from the commitmessage but that was redundant as the default changelog now handles release notice footersin its own section.

… descriptionsBREAKING CHANGE: Any release notice footer messages that the commit parser detects willnow be removed from the `commit.descriptions[]` list but maintained in and only in the`commit.notices[]` list. Previously, the descriptions included all text from the commitmessage but that was redundant as the default changelog now handles release notice footersin its own section.

… descriptionsBREAKING CHANGE: Any release notice footer messages that the emoji commit parser detects willnow be removed from the `commit.descriptions[]` list but maintained in and only in the`commit.notices[]` list. Previously, the descriptions included all text from the commitmessage but that was redundant as the default changelog now handles release notice footers inits own section.

…atch trimmed commits

… on Windows

Changes the default behavior of PSR when the `allow_zero_version` settingis not provided.BREAKING CHANGE: This release switches the `allow_zero_version` default to `false`.This change is to encourage less `0.x` releases as the default but rather allow theexperienced developer to choose when `0.x` is appropriate. There are way too manyprojects in the ecosystems that never leave `0.x` and that is problematic for theindustry tools that help auto-update based on SemVer. We should strive for publishingusable tools and maintaining good forethought for when compatibility must break. Ifyour configuration already sets the `allow_zero_version` value, this change willhave no effect on your project. If you want to use `0.x` versions, from the startthen change `allow_zero_version` to `true` in your configuration.

… the description

…sion=False`

…elease` default to `true`Changes the default behavior of PSR when `mask_initial_release` settingis not provided.BREAKING CHANGE: This release switches the `changelog.default_templates.mask_initial_release`default to `true`. This change is intended to toggle better recommended outputs of thedefault changelog. Conceptually, the very first release is hard to describe--one can onlyprovide new features as nothing exists yet for the end user. No changelog should be writtenas there is no start point to compare the "changes" to. The recommendation instead is to onlylist a simple message as `Initial Release`. This is now the default for PSR when providingthe very first release (no pre-existing tags) in the changelog and release notes. If yourconfiguration already sets the `changelog.default_templates.mask_initial_release` value, thenthis change will have no effect on your project. If you do NOT want to mask the first releaseinformation, then set `changelog.default_templates.mask_initial_release` to `false` in yourconfiguration.

…k_initial_release` value

…sk_initial_release`

Changes the default behavior of PSR when `changelog.mode` setting is notprovided.BREAKING CHANGE: This release switches the `changelog.mode` default to `update`. Inthis mode, if a changelog exists, PSR will update the changelog **IF AND ONLY IF**the configured insertion flag exists in the changelog. The Changelog output willremain unchanged if no insertion flag exists. The insertion flag may be configuredwith the `changelog.insertion_flag` setting. When upgrading to `v10`, you must addthe insertion flag manually or you can just delete the changelog file and run PSR'schangelog generation and it will rebuild the changelog (similar to init mode) butit will add the insertion flag. If your configuration already sets the`changelog.mode` value, then this change will have no effect on your project. If youwould rather the changelog be generated from scratch every release, than set the`changelog.mode` value to `init` in your configuration.

… the setting description# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.## On branch brk/changelog-update-as-default# Changes to be committed:#modified:   docs/configuration.rst#

…update`

…osure reference

…ure footers