…ventional/`

Remove the code that writes out the rest of the commit message from the default
template.

BREAKING CHANGE: The default Markdown changelog template and release notes template
will no longer print out the entire commit message contents, instead, it will only
print the commit subject line. This comes to meet the high demand of better formatted
changelogs and requests for subject line only. Originally, it was a decision to not
hide 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-in
parsers have the ability to parse squashed commits and separate them out into their
own entry on the changelog. Therefore, the default template no longer needs to write
out the full commit body. See the commit parser options if you want to enable/disable
parsing squash commits.

Resolves: python-semantic-release#733

…tructuredText template

Remove the code that writes out the rest of the commit message from the default
template.

BREAKING CHANGE: The default ReStructured changelog template
will no longer print out the entire commit message contents, instead, it will only
print the commit subject line. This comes to meet the high demand of better formatted
changelogs and requests for subject line only. Originally, it was a decision to not
hide 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-in
parsers have the ability to parse squashed commits and separate them out into their
own entry on the changelog. Therefore, the default template no longer needs to write
out the full commit body. See the commit parser options if you want to enable/disable
parsing squash commits.

Resolves: python-semantic-release#733

…e deprecating angular parser

…cating angular parser

…escriptions

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

…ions

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

…ions

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

…m commit descriptions

BREAKING CHANGE: Any breaking change footer messages that the conventional commit parser
detects will now be removed from the `commit.descriptions[]` list but maintained in and only
in the `commit.breaking_descriptions[]` list. Previously, the descriptions included
all text from the commit message but that was redundant as the default changelog now
handles breaking change footers in its own section.

… commit descriptions

BREAKING CHANGE: Any release notice footer messages that the commit parser detects will
now 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 commit
message but that was redundant as the default changelog now handles release notice footers
in its own section.

… descriptions

BREAKING CHANGE: Any release notice footer messages that the commit parser detects will
now 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 commit
message but that was redundant as the default changelog now handles release notice footers
in its own section.

… descriptions

BREAKING CHANGE: Any release notice footer messages that the emoji commit parser detects will
now 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 commit
message but that was redundant as the default changelog now handles release notice footers in
its own section.

…atch trimmed commits

… on Windows

Changes the default behavior of PSR when the `allow_zero_version` setting
is 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 the
experienced developer to choose when `0.x` is appropriate. There are way too many
projects in the ecosystems that never leave `0.x` and that is problematic for the
industry tools that help auto-update based on SemVer. We should strive for publishing
usable tools and maintaining good forethought for when compatibility must break. If
your configuration already sets the `allow_zero_version` value, this change will
have no effect on your project. If you want to use `0.x` versions, from the start
then 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` setting
is 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 the
default changelog. Conceptually, the very first release is hard to describe--one can only
provide new features as nothing exists yet for the end user. No changelog should be written
as there is no start point to compare the "changes" to. The recommendation instead is to only
list a simple message as `Initial Release`. This is now the default for PSR when providing
the very first release (no pre-existing tags) in the changelog and release notes. If your
configuration already sets the `changelog.default_templates.mask_initial_release` value, then
this change will have no effect on your project. If you do NOT want to mask the first release
information, then set `changelog.default_templates.mask_initial_release` to `false` in your
configuration.

…k_initial_release` value

…sk_initial_release`

Changes the default behavior of PSR when `changelog.mode` setting is not
provided.

BREAKING CHANGE: This release switches the `changelog.mode` default to `update`. In
this 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 will
remain unchanged if no insertion flag exists. The insertion flag may be configured
with the `changelog.insertion_flag` setting. When upgrading to `v10`, you must add
the insertion flag manually or you can just delete the changelog file and run PSR's
changelog generation and it will rebuild the changelog (similar to init mode) but
it 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 you
would 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