python-semantic-release 9.17.0__tar.gz → 9.20.0__tar.gz

{python_semantic_release-9.17.0/src/python_semantic_release.egg-info → python_semantic_release-9.20.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.17.0
+Version: 9.20.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT
@@ -33,6 +33,7 @@ Requires-Dist: importlib-resources~=6.0
 Requires-Dist: pydantic~=2.0
 Requires-Dist: rich~=13.0
 Requires-Dist: shellingham~=1.5
+Requires-Dist: Deprecated~=1.2
 Provides-Extra: build
 Requires-Dist: build~=1.2; extra == "build"
 Provides-Extra: docs
@@ -62,7 +63,8 @@ Requires-Dist: pre-commit~=3.5; extra == "dev"
 Requires-Dist: tox~=4.11; extra == "dev"
 Requires-Dist: ruff==0.6.1; extra == "dev"
 Provides-Extra: mypy
-Requires-Dist: mypy==1.14.1; extra == "mypy"
+Requires-Dist: mypy==1.15.0; extra == "mypy"
+Requires-Dist: types-Deprecated~=1.2; extra == "mypy"
 Requires-Dist: types-requests~=2.32.0; extra == "mypy"
 Requires-Dist: types-pyyaml~=6.0; extra == "mypy"
 

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/algorithm.rst

@@ -35,7 +35,7 @@ Implementation
 
 1. Parse all the Git tags of the repository into semantic versions, and **sort**
    in descending (most recent first) order according to `semver precedence`_.
-   Ignore any tags which do not correspond to valid semantic vesrions according
+   Ignore any tags which do not correspond to valid semantic versions according
    to ``tag_format``.
 
 

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/automatic-releases/github-actions.rst

@@ -337,7 +337,7 @@ before the :ref:`version <cmd-version>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/python-semantic-release@v9.16.1
+    - uses: python-semantic-release/python-semantic-release@v9.19.1
       with:
         root_options: "-vv --noop"
 
@@ -576,7 +576,7 @@ before the :ref:`publish <cmd-publish>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/publish-action@v9.16.1
+    - uses: python-semantic-release/publish-action@v9.19.1
       with:
         root_options: "-vv --noop"
 
@@ -684,7 +684,7 @@ to the GitHub Release Assets as well.
           - name: Action | Semantic Version Release
             id: release
             # Adjust tag with desired version if applicable.
-            uses: python-semantic-release/python-semantic-release@v9.16.1
+            uses: python-semantic-release/python-semantic-release@v9.19.1
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
               git_committer_name: "github-actions"
@@ -695,7 +695,7 @@ to the GitHub Release Assets as well.
             if: steps.release.outputs.released == 'true'
 
           - name: Publish | Upload to GitHub Release Assets
-            uses: python-semantic-release/publish-action@v9.16.1
+            uses: python-semantic-release/publish-action@v9.19.1
             if: steps.release.outputs.released == 'true'
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -744,7 +744,7 @@ The equivalent GitHub Action configuration would be:
 
   - name: Action | Semantic Version Release
     # Adjust tag with desired version if applicable.
-    uses: python-semantic-release/python-semantic-release@v9.16.1
+    uses: python-semantic-release/python-semantic-release@v9.19.1
     with:
       github_token: ${{ secrets.GITHUB_TOKEN }}
       force: patch
@@ -772,13 +772,13 @@ Publish Action.
 .. code:: yaml
 
    - name: Release Project 1
-     uses: python-semantic-release/python-semantic-release@v9.16.1
+     uses: python-semantic-release/python-semantic-release@v9.19.1
      with:
        directory: ./project1
        github_token: ${{ secrets.GITHUB_TOKEN }}
 
    - name: Release Project 2
-     uses: python-semantic-release/python-semantic-release@v9.16.1
+     uses: python-semantic-release/python-semantic-release@v9.19.1
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/automatic-releases/index.rst

@@ -13,6 +13,8 @@ Guides
 ^^^^^^
 
 .. toctree::
+    :maxdepth: 2
+
     travis
     github-actions
     cronjobs

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/changelog_templates.rst

@@ -49,7 +49,7 @@ PSR provides two default changelog output formats:
 Both formats are kept in sync with one another to display the equivalent information
 in the respective format. The default changelog template is located in the
 ``data/templates/`` directory within the PSR package. The templates are written in
-modular style (ie. multiple files) and during the render proccess are ultimately
+modular style (ie. multiple files) and during the render process are ultimately
 combined together to render the final changelog output. The rendering start point
 is the ``CHANGELOG.{FORMAT_EXT}.j2`` underneath the respective format directory.
 
@@ -71,8 +71,8 @@ A common and *highly-recommended* configuration option is the
 :ref:`changelog.exclude_commit_patterns <config-changelog-exclude_commit_patterns>`
 setting which allows the user to define regular expressions that will exclude commits
 from the changelog output. This is useful to filter out change messages that are not
-relevant to your external consumers (ex. ``ci`` and ``test`` in the angular commit
-convention) and only include the important changes that impact the consumer of your
+relevant to your external consumers (ex. ``ci`` and ``test`` in the conventional commit
+standard) and only include the important changes that impact the consumer of your
 software.
 
 Another important configuration option is the :ref:`changelog.mode <config-changelog-mode>`
@@ -144,7 +144,7 @@ newly created changelog file.
 
 .. tip::
     We have accomplished changelog updating through the use of the `Jinja`_ templating
-    and addtional context filters and context variables. This is notable because
+    and additional context filters and context variables. This is notable because
     in the case that you want to customize your changelog template, you now can use the
     same logic to enable changelog updates of your custom template!
 
@@ -228,7 +228,7 @@ Configuration Examples
           }
         }
 
-3.  Goal: Configure an initializing reStructuredText changelog with filtered angular
+3.  Goal: Configure an initializing reStructuredText changelog with filtered conventional
     commits patterns and merge commits within a custom config file ``releaserc.toml``.
 
     .. code:: toml
@@ -246,6 +246,11 @@ Configuration Examples
           '''Merged? .*''',
         ]
 
+If identified or supported by the parser, the default changelog templates will include
+a separate section of breaking changes and additional release information. Refer to the
+:ref:`commit parsing <commit-parsing>` section to see how to write commit messages that
+will be properly parsed and displayed in these sections.
+
 
 .. _changelog-templates-default_release_notes:
 
@@ -260,16 +265,37 @@ default built-in template out-of-the-box for generating release notes.
 
 The difference between the changelog and release notes is that the release notes
 only contain the changes for the current release. Due to the modularity of the
-PSR templates, the format is identical to an individual version of the default
-changelog.
+PSR templates, the format is similar to an individual version of the default
+changelog but may include other version specific information.
 
 At this time, the default template for version release notes is only available
 in Markdown format for all VCS types.
 
+If you want to review what the default release notes look like you can use the
+following command to print the release notes to the console (remove any configuration
+for defining a custom template directory):
+
+.. code:: console
+
+    # Create a current tag
+    git tag v1.0.0
+    semantic-release --noop changelog --post-to-release-tag v1.0.0
+
+The default template provided by PSR will respect the
+:ref:`config-changelog-default_templates-mask_initial_release` setting and
+will also add a comparison link to the previous release if one exists without
+customization.
+
+As of ``v9.18.0``, the default release notes will also include a statement to
+declare which license the project was released under. PSR determines which license
+to declare based on the value of ``project.license-expression`` in the ``pyproject.toml``
+file as defined in the `PEP 639`_ specification.
+
 .. seealso::
     - To personalize your release notes, see the
       :ref:`changelog-templates-custom_release_notes` section.
 
+.. _PEP 639: https://peps.python.org/pep-0639/
 
 .. _changelog-templates-template-rendering:
 
@@ -658,6 +684,45 @@ The filters provided vary based on the VCS configured and available features:
           )
       }}
 
+* ``create_pypi_url(package_name: str, version: str = "")``: given a package name and an optional
+  version, return a URL to the PyPI page for the package. If a version is provided, the URL will
+  point to the specific version page. If no version is provided, the URL will point to the package
+  page.
+
+  *Introduced in v9.18.0.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "example-package" | create_pypi_url }}
+      {{ "example-package" | create_pypi_url("1.0.0") }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      https://pypi.org/project/example-package
+      https://pypi.org/project/example-package/1.0.0
+
+* ``create_release_url (Callable[[TagStr], UrlStr])``: given a tag, return a URL to the release
+  page on the remote vcs. This filter is useful when you want to link to the release page on the
+  remote vcs.
+
+  *Introduced in v9.18.0.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "v1.0.0" | create_release_url }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      https://example.com/example/repo/releases/tag/v1.0.0
+
 * ``create_server_url (Callable[[PathStr, AuthStr | None, QueryStr | None, FragmentStr | None], UrlStr])``:
   when given a path, prepend the configured vcs server host and url scheme.  Optionally you
   can provide, a auth string, a query string or a url fragment to be normalized into the
@@ -817,6 +882,29 @@ The filters provided vary based on the VCS configured and available features:
 
       [#29](https://example.com/example/repo/pull/29)
 
+* ``format_w_official_vcs_name (Callable[[str], str])``: given a format string, insert
+  the official VCS type name into the string and return. This filter is useful when you want to
+  display the proper name of the VCS type in a changelog or release notes. The filter supports
+  three different replace formats: ``%s``, ``{}``, and ``{vcs_name}``.
+
+  *Introduced in v9.18.0.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "%s Releases" | format_w_official_vcs_name }}
+      {{ "{} Releases" | format_w_official_vcs_name }}
+      {{ "{vcs_name} Releases" | format_w_official_vcs_name }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      GitHub Releases
+      GitHub Releases
+      GitHub Releases
+
 * ``read_file (Callable[[str], str])``: given a file path, read the file and
   return the contents as a string. This function was added specifically to
   enable the changelog update feature where it would load the existing changelog
@@ -858,21 +946,24 @@ The filters provided vary based on the VCS configured and available features:
 
 Availability of the documented filters can be found in the table below:
 
-======================  =========  =====  ======  ======
-**filter - hvcs_type**  bitbucket  gitea  github  gitlab
-======================  =========  =====  ======  ======
-autofit_text_width         ✅       ✅      ✅      ✅
-convert_md_to_rst          ✅       ✅      ✅      ✅
-create_server_url          ✅       ✅      ✅      ✅
-create_repo_url            ✅       ✅      ✅      ✅
-commit_hash_url            ✅       ✅      ✅      ✅
-compare_url                ✅       ❌      ✅      ✅
-issue_url                  ❌       ✅      ✅      ✅
-merge_request_url          ❌       ❌      ❌      ✅
-pull_request_url           ✅       ✅      ✅      ✅
-read_file                  ✅       ✅      ✅      ✅
-sort_numerically           ✅       ✅      ✅      ✅
-======================  =========  =====  ======  ======
+==========================  =========  =====  ======  ======
+**filter - hvcs_type**      bitbucket  gitea  github  gitlab
+==========================  =========  =====  ======  ======
+autofit_text_width             ✅       ✅      ✅      ✅
+convert_md_to_rst              ✅       ✅      ✅      ✅
+create_pypi_url                ✅       ✅      ✅      ✅
+create_server_url              ✅       ✅      ✅      ✅
+create_release_url             ❌       ✅      ✅      ✅
+create_repo_url                ✅       ✅      ✅      ✅
+commit_hash_url                ✅       ✅      ✅      ✅
+compare_url                    ✅       ❌      ✅      ✅
+format_w_official_vcs_name     ✅       ✅      ✅      ✅
+issue_url                      ❌       ✅      ✅      ✅
+merge_request_url              ❌       ❌      ❌      ✅
+pull_request_url               ✅       ✅      ✅      ✅
+read_file                      ✅       ✅      ✅      ✅
+sort_numerically               ✅       ✅      ✅      ✅
+==========================  =========  =====  ======  ======
 
 .. seealso::
    * `Filters <https://jinja.palletsprojects.com/en/3.1.x/templates/#filters>`_
@@ -1129,7 +1220,7 @@ __ https://github.com/python-semantic-release/python-semantic-release/tree/maste
     maintain any content that should be included before the new release information.
     See ``data/templates/*/md/.components/changelog_update.md.j2`` for reference.
 
-5.  **Print your insertion flag.** This is impartive to ensure that the resulting
+5.  **Print your insertion flag.** This is imperative to ensure that the resulting
     changelog can be updated in the future. See
     ``data/templates/*/md/.components/changelog_update.md.j2`` for reference.
 

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/commands.rst

@@ -272,8 +272,8 @@ the flag.
 This can be useful when making a single prerelease on a branch that would typically release
 normal versions.
 
-If not specified in :ref:`cmd-version-option-prerelease-token`, the prerelease token is idenitified using the
-:ref:`Multibranch Release Configuration <multibranch-releases-configuring>`
+If not specified in :ref:`cmd-version-option-prerelease-token`, the prerelease token is identified
+using the :ref:`Multibranch Release Configuration <multibranch-releases-configuring>`
 
 See the examples alongside :ref:`cmd-version-option-force-level` for how to use this flag.
 
@@ -282,8 +282,9 @@ See the examples alongside :ref:`cmd-version-option-force-level` for how to use
 ``--prerelease-token [VALUE]``
 ******************************
 
-Force the next version to use the value as the prerelease token. This overrides the configured value if one is
-present. If not used during a release producing a prerelease version, this option has no effect.
+Force the next version to use the value as the prerelease token. This overrides the configured
+value if one is present. If not used during a release producing a prerelease version, this
+option has no effect.
 
 .. _cmd-version-option-build-metadata:
 

{python_semantic_release-9.17.0 → python_semantic_release-9.20.0}/docs/commit_parsing.rst

@@ -33,7 +33,7 @@ to handle your specific commit message style.
   features are added beyond the scope of the original commit message style guidelines.
 
   Other tools may not follow the same conventions as PSR's guideline extensions, so
-  if you plan to use any similar programs in tadem with PSR, you should be aware of the
+  if you plan to use any similar programs in tandem with PSR, you should be aware of the
   differences in feature support and fall back to the official format guidelines if
   necessary.
 
@@ -48,27 +48,110 @@ Built-in Commit Parsers
 
 The following parsers are built in to Python Semantic Release:
 
-- :ref:`AngularCommitParser <commit_parser-builtin-angular>`
+- :ref:`ConventionalCommitParser <commit_parser-builtin-conventional>`
+- :ref:`AngularCommitParser <commit_parser-builtin-angular>` *(deprecated in v9.19.0)*
 - :ref:`EmojiCommitParser <commit_parser-builtin-emoji>`
 - :ref:`ScipyCommitParser <commit_parser-builtin-scipy>`
 - :ref:`TagCommitParser <commit_parser-builtin-tag>` *(deprecated in v9.12.0)*
 
 ----
 
+.. _commit_parser-builtin-conventional:
+
+Conventional Commits Parser
+"""""""""""""""""""""""""""
+
+*Introduced in v9.19.0*
+
+A parser that is designed to parse commits formatted according to the
+`Conventional Commits Specification`_.  The parser is implemented with the following
+logic in relation to how PSR's core features:
+
+- **Version Bump Determination**: This parser extracts the commit type from the subject
+  line of the commit (the first line of a commit message). This type is matched against
+  the configuration mapping to determine the level bump for the specific commit. If the
+  commit type is not found in the configuration mapping, the commit is considered a
+  non-parsable commit and will return it as a ParseError object and ultimately a commit
+  of type ``"unknown"``. The configuration mapping contains lists of commit types that
+  correspond to the level bump for each commit type. Some commit types are still valid
+  do not trigger a level bump, such as ``"chore"`` or ``"docs"``. You can also configure
+  the default level bump
+  :ref:`commit_parser_options.default_level_bump <config-commit_parser_options>` if desired.
+  To trigger a major release, the commit message body must contain a paragraph that begins
+  with ``BREAKING CHANGE:``. This will override the level bump determined by the commit type.
+
+- **Changelog Generation**: PSR will group commits in the changelog by the commit type used
+  in the commit message. The commit type shorthand is converted to a more human-friendly
+  section heading and then used as the version section title of the changelog and release
+  notes. Under the section title, the parsed commit descriptions are listed out in full. If
+  the commit includes an optional scope, then the scope is prefixed on to the first line of
+  the commit description. If a commit has any breaking change prefixed paragraphs in the
+  commit message body, those paragraphs are separated out into a "Breaking Changes" section
+  in the changelog (Breaking Changes section is available from the default changelog in
+  v9.15.0). Each breaking change paragraph is listed in a bulleted list format across the
+  entire version. A single commit is allowed to have more than one breaking change
+  prefixed paragraph (as opposed to the `Conventional Commits Specification`_). Commits
+  with an optional scope and a breaking change will have the scope prefixed on to the
+  breaking change paragraph. Parsing errors will return a ParseError object and ultimately
+  a commit of type ``"unknown"``. Unknown commits are consolidated into an "Unknown" section
+  in the changelog by the default template. To remove unwanted commits from the changelog
+  that normally are placed in the "unknown" section, consider the use of the configuration
+  option :ref:`changelog.exclude_commit_patterns <config-changelog-exclude_commit_patterns>`
+  to ignore those commit styles.
+
+- **Pull/Merge Request Identifier Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-linked_merge_request_detection` to identify and extract
+  pull/merge request numbers. The parser will return a string value if a pull/merge
+  request number is found in the commit message. If no pull/merge request number is
+  found, the parser will return an empty string.
+
+- **Linked Issue Identifier Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-issue_number_detection` to identify and extract issue numbers.
+  The parser will return a tuple of issue numbers as strings if any are found in the commit
+  message. If no issue numbers are found, the parser will return an empty tuple.
+
+- **Squash Commit Evaluation**: This parser implements PSR's
+  :ref:`commit_parser-builtin-squash_commit_evaluation` to identify and extract each commit
+  message as a separate commit message within a single squashed commit. You can toggle this
+  feature on/off via the :ref:`config-commit_parser_options` setting.
+
+- **Release Notice Footer Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-release_notice_footer_detection`, which is a custom extension
+  to traditional `Conventional Commits Specification`_ to use the ``NOTICE`` keyword as a git
+  footer to document additional release information that is not considered a breaking change.
+
+**Limitations**:
+
+- Commits with the ``revert`` type are not currently supported. Track the implementation
+  of this feature in the issue `#402`_.
+
+If no commit parser options are provided via the configuration, the parser will use PSR's
+built-in
+:py:class:`defaults <semantic_release.commit_parser.conventional.ConventionalCommitParserOptions>`.
+
+.. _#402: https://github.com/python-semantic-release/python-semantic-release/issues/402
+.. _Conventional Commits Specification: https://www.conventionalcommits.org/en/v1.0.0
+
+----
+
 .. _commit_parser-builtin-angular:
 
 Angular Commit Parser
 """""""""""""""""""""
 
+.. warning::
+  This parser was deprecated in ``v9.19.0``. It will be removed in a future release.
+  This parser is being replaced by the :ref:`commit_parser-builtin-conventional`.
+
 A parser that is designed to parse commits formatted according to the
 `Angular Commit Style Guidelines`_.  The parser is implemented with the following
 logic in relation to how PSR's core features:
 
 - **Version Bump Determination**: This parser extracts the commit type from the subject
-  line of the commit (the first line of a commit messsage). This type is matched against
+  line of the commit (the first line of a commit message). This type is matched against
   the configuration mapping to determine the level bump for the specific commit. If the
   commit type is not found in the configuration mapping, the commit is considered a
-  non-conformative commit and will return it as a ParseError object and ultimately a commit
+  non-parsable commit and will return it as a ParseError object and ultimately a commit
   of type ``"unknown"``. The configuration mapping contains lists of commit types that
   correspond to the level bump for each commit type. Some commit types are still valid
   do not trigger a level bump, such as ``"chore"`` or ``"docs"``. You can also configure
@@ -114,6 +197,12 @@ logic in relation to how PSR's core features:
   feature on/off via the :ref:`config-commit_parser_options` setting. *Feature available in
   v9.17.0+.*
 
+- **Release Notice Footer Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-release_notice_footer_detection`, which is a custom extension
+  to traditional `Angular Commit Style Guidelines`_ to use the ``NOTICE`` keyword as a git
+  footer to document additional release information that is not considered a breaking change.
+  *Feature available in v9.18.0+.*
+
 **Limitations**:
 
 - Commits with the ``revert`` type are not currently supported. Track the implementation
@@ -123,10 +212,7 @@ If no commit parser options are provided via the configuration, the parser will
 built-in :py:class:`defaults <semantic_release.commit_parser.angular.AngularParserOptions>`.
 
 .. _#402: https://github.com/python-semantic-release/python-semantic-release/issues/402
-.. _#733: https://github.com/python-semantic-release/python-semantic-release/issues/733
-.. _#1085: https://github.com/python-semantic-release/python-semantic-release/issues/1085
 .. _Angular Commit Style Guidelines: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits
-.. _PR#1112: https://github.com/python-semantic-release/python-semantic-release/pull/1112
 
 ----
 
@@ -145,7 +231,7 @@ commit messages. The parser is implemented with the following logic in relation
 how PSR's core features:
 
 - **Version Bump Determination**: This parser only looks for emojis in the subject
-  line of the commit (the first line of a commit messsage). If more than one emoji is
+  line of the commit (the first line of a commit message). If more than one emoji is
   found, the emoji configured with the highest priority is selected for the change impact
   for the specific commit. The emoji with the highest priority is the one configured in the
   ``major`` configuration option, followed by the ``minor``, and ``patch`` in descending
@@ -185,6 +271,11 @@ how PSR's core features:
   feature on/off via the :ref:`config-commit_parser_options` setting. *Feature available in
   v9.17.0+.*
 
+- **Release Notice Footer Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-release_notice_footer_detection`, which is a custom extension
+  that uses the ``NOTICE`` keyword as a git footer to document additional release information
+  that is not considered a breaking change. *Feature available in v9.18.0+.*
+
 If no commit parser options are provided via the configuration, the parser will use PSR's
 built-in :py:class:`defaults <semantic_release.commit_parser.emoji.EmojiParserOptions>`.
 
@@ -198,7 +289,7 @@ Scipy Commit Parser
 """""""""""""""""""
 
 A parser that is designed to parse commits formatted according to the
-`Scipy Commit Style Guidlines`_. This is essentially a variation of the `Angular Commit Style
+`Scipy Commit Style Guidelines`_. This is essentially a variation of the `Angular Commit Style
 Guidelines`_ with all different commit types. Because of this small variance, this parser
 only extends our :ref:`commit_parser-builtin-angular` parser with pre-defined scipy commit types
 in the default Scipy Parser Options and all other features are inherited.
@@ -206,7 +297,7 @@ in the default Scipy Parser Options and all other features are inherited.
 If no commit parser options are provided via the configuration, the parser will use PSR's
 built-in :py:class:`defaults <semantic_release.commit_parser.scipy.ScipyParserOptions>`.
 
-.. _Scipy Commit Style Guidlines: https://scipy.github.io/devdocs/dev/contributor/development_workflow.html#writing-the-commit-message
+.. _Scipy Commit Style Guidelines: https://scipy.github.io/devdocs/dev/contributor/development_workflow.html#writing-the-commit-message
 
 ----
 
@@ -235,7 +326,7 @@ Common Linked Merge Request Detection
 
 All of the PSR built-in parsers implement common pull/merge request identifier detection
 logic to extract pull/merge request numbers from the commit message regardless of the
-VCS platform. The parsers evaluate the subject line for a paranthesis-enclosed number
+VCS platform. The parsers evaluate the subject line for a parenthesis-enclosed number
 at the end of the line. PSR's parsers will return a string value if a pull/merge request
 number is found in the commit message. If no pull/merge request number is found, the
 parsers will return an empty string.
@@ -280,7 +371,7 @@ for your VCS. PSR supports the following case-insensitive prefixes and their con
 - implement (implements, implementing, implemented)
 
 PSR also allows for a more flexible approach to identifying more than one issue number without
-the need of extra git trailors (although PSR does support multiple git trailors). PSR support
+the need of extra git trailers (although PSR does support multiple git trailers). PSR support
 various list formats which can be used to identify more than one issue in a list. This format
 will not necessarily work on your VCS. PSR currently support the following list formats:
 
@@ -310,6 +401,33 @@ return an empty tuple.
 
 ----
 
+.. _commit_parser-builtin-release_notice_footer_detection:
+
+Common Release Notice Footer Detection
+""""""""""""""""""""""""""""""""""""""
+
+*Introduced in v9.18.0**
+
+All of the PSR built-in parsers implement common release notice footer detection logic
+to identify and extract a ``NOTICE`` git trailer that documents any additional release
+information the developer wants to provide to the software consumer. The idea extends
+from the concept of the ``BREAKING CHANGE:`` git trailer to document any breaking change
+descriptions but the ``NOTICE`` trailer is intended to document any information that is
+below the threshold of a breaking change while still important for the software consumer
+to be aware of. Common uses would be to provide deprecation warnings or more detailed
+change usage information for that release. Parsers will collapse single newlines after
+the ``NOTICE`` trailer into a single line paragraph. Commits may have more than one
+``NOTICE`` trailer in a single commit message. Each
+:py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>` will have
+a ``release_notices`` attribute that is a tuple of string paragraphs to identify each
+release notice.
+
+In the default changelog and release notes template, these release notices will be
+formatted into their own section called **Additional Release Information**. Each will
+include any commit scope defined and each release notice in alphabetical order.
+
+----
+
 .. _commit_parser-builtin-squash_commit_evaluation:
 
 Common Squash Commit Evaluation
@@ -326,7 +444,7 @@ will be evaluated individually for both the level bump and changelog generation.
 squash commits are found, a list with the single commit object will be returned.
 
 Currently, PSR has been tested against GitHub, BitBucket, and official ``git`` squash
-merge commmit messages. GitLab does not have a default template for squash commit messages
+merge commit messages. GitLab does not have a default template for squash commit messages
 but can be customized per project or server. If you are using GitLab, you will need to
 ensure that the squash commit message format is similar to the example below.
 
@@ -343,10 +461,10 @@ formatted squash commit message of conventional commit style:*
 
     * docs(configuration): defined new config option for the project
 
-When parsed with the default angular parser with squash commits toggled on, the version
-bump will be determined by the highest level bump of the three commits (in this case, a
-minor bump because of the feature commit) and the release notes would look similar to
-the following:
+When parsed with the default conventional-commit parser with squash commits toggled on,
+the version bump will be determined by the highest level bump of the three commits (in
+this case, a minor bump because of the feature commit) and the release notes would look
+similar to the following:
 
 .. code-block:: markdown
 
@@ -544,7 +662,8 @@ A subclass must implement the following:
   :py:class:`ParseResult <semantic_release.commit_parser.token.ParseResult>`, or a
   subclass of this.
 
-By default, the constructor for :py:class:`CommitParser <semantic_release.commit_parser._base.CommitParser>`
+By default, the constructor for
+:py:class:`CommitParser <semantic_release.commit_parser._base.CommitParser>`
 will set the ``options`` parameter on the ``options`` attribute of the parser, so there
 is no need to override this in order to access ``self.options`` during the ``parse``
 method. However, if you have any parsing logic that needs to be done only once, it may
@@ -572,5 +691,4 @@ Therefore, a custom commit parser could be implemented via:
         def parse(self, commit: git.objects.commit.Commit) -> semantic_release.ParseResult:
             ...
 
-.. _angular commit guidelines: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits
 .. _gitpython-commit-object: https://gitpython.readthedocs.io/en/stable/reference.html#module-git.objects.commit