python-semantic-release 9.18.1__tar.gz → 9.19.1__tar.gz

{python_semantic_release-9.18.1/src/python_semantic_release.egg-info → python_semantic_release-9.19.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.18.1
+Version: 9.19.1
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT
@@ -62,7 +62,7 @@ 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-requests~=2.32.0; extra == "mypy"
 Requires-Dist: types-pyyaml~=6.0; extra == "mypy"
 

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/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.18.1 → python_semantic_release-9.19.1}/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.18.0
+    - uses: python-semantic-release/python-semantic-release@v9.19.0
       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.18.0
+    - uses: python-semantic-release/publish-action@v9.19.0
       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.18.0
+            uses: python-semantic-release/python-semantic-release@v9.19.0
             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.18.0
+            uses: python-semantic-release/publish-action@v9.19.0
             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.18.0
+    uses: python-semantic-release/python-semantic-release@v9.19.0
     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.18.0
+     uses: python-semantic-release/python-semantic-release@v9.19.0
      with:
        directory: ./project1
        github_token: ${{ secrets.GITHUB_TOKEN }}
 
    - name: Release Project 2
-     uses: python-semantic-release/python-semantic-release@v9.18.0
+     uses: python-semantic-release/python-semantic-release@v9.19.0
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/automatic-releases/index.rst

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

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/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
@@ -282,7 +282,7 @@ for defining a custom template directory):
     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
+: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.
 
@@ -1220,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.18.1 → python_semantic_release-9.19.1}/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.18.1 → python_semantic_release-9.19.1}/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
@@ -129,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
 
 ----
 
@@ -151,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
@@ -209,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.
@@ -217,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
 
 ----
 
@@ -246,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.
@@ -291,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:
 
@@ -343,7 +423,7 @@ a ``release_notices`` attribute that is a tuple of string paragraphs to identify
 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
+formatted into their own section called **Additional Release Information**. Each will
 include any commit scope defined and each release notice in alphabetical order.
 
 ----
@@ -364,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.
 
@@ -381,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
 
@@ -582,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
@@ -610,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

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/configuration.rst

@@ -88,9 +88,12 @@ environment variable is:
     default = "default value"
 
 In this structure:
+
   * ``env`` represents the environment variable that Python Semantic Release will search for
+
   * ``default_env`` is a fallback environment variable to read in case the variable specified
     by ``env`` is not set. This is optional - if not specified then no fallback will be used.
+
   * ``default`` is a default value to use in case the environment variable specified by ``env``
     is not set. This is optional - if ``default`` is not specified then the environment variable
     specified by ``env`` is considered required.
@@ -105,7 +108,7 @@ configuration setting. If there are type mis-matches, PSR will throw validation
 If a setting is not provided, than PSR will fill in the value with the default value.
 
 Python Semantic Release expects a root level key to start the configuration definition. Make
-sure to use the correct root key dependending on the configuration format you are using.
+sure to use the correct root key depending on the configuration format you are using.
 
 .. note:: If you are using ``pyproject.toml``, this heading should include the ``tool`` prefix
           as specified within PEP 517, resulting in ``[tool.semantic_release]``.
@@ -405,7 +408,7 @@ This setting is used to specify the output format the default changelog template
 will use when rendering the changelog. PSR supports both Markdown (``md``) and
 reStructuredText (``rst``) formats.
 
-This setting will take presendence over the file extension of the
+This setting will take precedence over the file extension of the
 :ref:`config-changelog-default_templates-changelog_file` setting. If this setting is
 omitted, the file extension of the :ref:`config-changelog-default_templates-changelog_file`
 setting will be used to determine the output format. If the file extension is not recognized,
@@ -695,10 +698,6 @@ A string that will be used to identify where the new version should be inserted
 changelog file (as defined by :ref:`config-changelog-changelog_file`) when the changelog mode
 is set to ``update``.
 
-When the changelog mode is set to ``init``, this string will be included as part of the
-header of the changelog file to initialize the changelog with a format that will be condusive
-for future version insertions.
-
 If you modify this value in your config, you will need to manually update any saved changelog
 file to match the new insertion flag if you use the ``update`` mode.  In ``init`` mode, the
 changelog file will be overwritten as normal.
@@ -790,7 +789,8 @@ Specify which commit parser Python Semantic Release should use to parse the comm
 within the Git repository.
 
 Built-in parsers:
-    * ``angular`` - :ref:`AngularCommitParser <commit_parser-builtin-angular>`
+    * ``angular`` - :ref:`AngularCommitParser <commit_parser-builtin-angular>` *(deprecated in v9.19.0)*
+    * ``conventional`` - :ref:`ConventionalCommitParser <commit_parser-builtin-conventional>` *(available in v9.19.0+)*
     * ``emoji`` - :ref:`EmojiCommitParser <commit_parser-builtin-emoji>`
     * ``scipy`` - :ref:`ScipyCommitParser <commit_parser-builtin-scipy>`
     * ``tag`` - :ref:`TagCommitParser <commit_parser-builtin-tag>` *(deprecated in v9.12.0)*
@@ -800,7 +800,7 @@ your own commit parser in ``path/to/module_file.py:Class`` or ``module:Class`` f
 
 For more information see :ref:`commit-parsing`.
 
-**Default:** ``"angular"``
+**Default:** ``"conventional"``
 
 ----
 
@@ -964,7 +964,7 @@ calls rather than the primary domain (ex. ``api.github.com``).
 
 **Most on-premise HVCS installations will NOT use this setting!** Whether or not
 this value is used depends on the HVCS configured (and your server administration)
-in the :ref:`remote.type <config-remote-type>` setting and used in tadem with the
+in the :ref:`remote.type <config-remote-type>` setting and used in tandem with the
 :ref:`remote.domain <config-remote-domain>` setting.
 
 When using a custom :ref:`remote.domain <config-remote-domain>` and a HVCS
@@ -1057,7 +1057,7 @@ used for the connection. If the protocol scheme is provided in the field value,
 match this setting or it will throw an error.
 
 The purpose of this flag is to prevent any typos in provided ``domain`` and ``api_domain``
-values that accidently specify an insecure connection but allow users to toggle the protection
+values that accidentally specify an insecure connection but allow users to toggle the protection
 scheme off when desired.
 
 **Default:** ``false``

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/index.rst

@@ -140,9 +140,8 @@ Setting up commit parsing
 -------------------------
 
 We rely on commit messages to detect when a version bump is needed.
-By default, Python Semantic Release uses the
-`Angular style <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits>`_.
-You can find out more about this in :ref:`commit-parsing`.
+By default, Python Semantic Release uses the `Conventional Commits Specification`_
+to parse commit messages. You can find out more about this in :ref:`commit-parsing`.
 
 .. seealso::
    - :ref:`config-branches` - Adding configuration for releases from multiple branches.
@@ -150,6 +149,8 @@ You can find out more about this in :ref:`commit-parsing`.
      For example, Python Semantic Release also ships with emoji and scipy-style parsers.
    - :ref:`remote.type <config-remote-type>` - specify the type of your remote VCS.
 
+.. _Conventional Commits Specification: https://www.conventionalcommits.org/en/v1.0.0
+
 Setting up the changelog
 ------------------------
 
@@ -218,7 +219,7 @@ and changelogs. The user has three options to push changes to the repository:
    - :ref:`Changelog <config-changelog>` - customize your project's changelog.
    - :ref:`changelog-templates-custom_release_notes` - customize the published release notes
    - :ref:`upload_to_vcs_release <config-publish-upload_to_vcs_release>` -
-     enable/disable uploading artefacts to VCS releases
+     enable/disable uploading artifacts to VCS releases
    - :ref:`version --vcs-release/--no-vcs-release <cmd-version-option-vcs-release>` - enable/disable VCS release
      creation.
    - `upload-to-gh-release`_, a GitHub Action for running ``semantic-release publish``

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/migrating_from_v7.rst

@@ -8,7 +8,7 @@ The internals have been changed significantly to better support highly-requested
 features and to streamline the maintenance of the project.
 
 As a result, certain things have been removed, reimplemented differently, or now
-exhibit different behaviour to earlier versions of Python Semantic Release. This
+exhibit different behavior to earlier versions of Python Semantic Release. This
 page is a guide to help projects to ``pip install python-semantic-release>=8.0.0`` with
 fewer surprises.
 
@@ -19,12 +19,12 @@ Python Semantic Release GitHub Action
 
 .. _breaking-removed-artefact-upload:
 
-GitHub Action no longer publishes artefacts to PyPI or GitHub Releases
+GitHub Action no longer publishes artifacts to PyPI or GitHub Releases
 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 
 Python Semantic Release no longer uploads distributions to PyPI - see
 :ref:`breaking-commands-repurposed-version-and-publish`. If you are
-using Python Semantic Release to publish release notes and artefacts to
+using Python Semantic Release to publish release notes and artifacts to
 GitHub releases, there is a new GitHub Action `upload-to-gh-release`_
 which will perform this action for you.
 
@@ -143,7 +143,7 @@ Repurposing of ``version`` and ``publish`` commands
 """""""""""""""""""""""""""""""""""""""""""""""""""
 Python Semantic Release's primary purpose is to enable automation of correct semantic
 versioning for software projects. Over the years, this automation has been extended to
-include other actions such as building/publishing the project and its artefacts to
+include other actions such as building/publishing the project and its artifacts to
 artefact repositories, creating releases in remote version control systems, and writing
 changelogs.
 
@@ -152,9 +152,9 @@ performing every piece of automation provided. This has been changed - the ``ver
 command now handles determining the next version, applying the changes to the project
 metadata according to the configuration, writing a changelog, and committing/pushing
 changes to the remote Git repository. It also handles creating a release in the remote
-VCS. It does *not* publish software artefacts to remote repositories such as PyPI;
+VCS. It does *not* publish software artifacts to remote repositories such as PyPI;
 the rationale behind this decision is simply that under the hood, Python Semantic Release
-used `twine`_ to upload artefacts to package indexes such as PyPI, and it's recommended
+used `twine`_ to upload artifacts to package indexes such as PyPI, and it's recommended
 to use twine directly via the command-line. From the twine
 `documentation <https://twine.readthedocs.io/en/stable/contributing.html#architectural-overview>`_:
 
@@ -162,7 +162,7 @@ to use twine directly via the command-line. From the twine
 
 As a result Python Semantic Release no longer depends on twine internals.
 
-The ``publish`` command now handles publishing software artefacts to releases in the
+The ``publish`` command now handles publishing software artifacts to releases in the
 remote version control system.
 
 .. _twine: https://twine.readthedocs.io/en/stable
@@ -477,17 +477,17 @@ tag ``v1.1.4``, you should run::
 
     semantic-release changelog --post-to-release-tag v1.1.4
 
-.. _breaking-changelog-customisation:
+.. _breaking-changelog-customization:
 
-Changelog customisation
+Changelog customization
 """""""""""""""""""""""
 
-A number of options relevant to customising the changelog have been removed. This is
+A number of options relevant to customizing the changelog have been removed. This is
 because Python Semantic Release now supports authoring a completely custom `Jinja`_
 template with the contents of your changelog.
 Historically, the number of options added to Python Semantic Release in order to
-allow this customisation has grown significantly; it now uses templates in order to
-fully open up customising the changelog's appearance.
+allow this customization has grown significantly; it now uses templates in order to
+fully open up customizing the changelog's appearance.
 
 .. _Jinja: https://jinja.palletsprojects.com/en/3.1.x/
 
@@ -499,7 +499,7 @@ Configuration
 
 The configuration structure has been completely reworked, so you should read
 :ref:`configuration` carefully during the process of upgrading to v8+. However,
-some common pitfalls and potential sources of confusion are summarised here.
+some common pitfalls and potential sources of confusion are summarized here.
 
 .. _breaking-configuration-setup-cfg-unsupported:
 
@@ -520,7 +520,7 @@ needs.
 .. warning::
 
    If you don't already have a ``pyproject.toml`` configuration file, ``pip`` can
-   change its behaviour once you add one, as a result of `PEP-517`_. If you find
+   change its behavior once you add one, as a result of `PEP-517`_. If you find
    that this breaks your packaging, you can add your Python Semantic Release
    configuration to a separate file such as ``semantic-release.toml``, and use
    the :ref:`--config <cmd-main-option-config>` option to reference this alternative
@@ -539,7 +539,7 @@ Commit parser options
 
 Options such as ``major_emoji``, ``parser_angular_patch_types`` or
 ``parser_angular_default_level_bump`` have been removed. Instead, these have been
-replaced with a single set of recognised commit parser options, ``allowed_tags``,
+replaced with a single set of recognized commit parser options, ``allowed_tags``,
 ``major_tags``, ``minor_tags``, and ``patch_tags``, though the interpretation of
 these is up to the specific parsers in use. You can read more detail about using
 commit parser options in :ref:`commit_parser_options <config-commit_parser_options>`,

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/multibranch_releases.rst

@@ -45,12 +45,12 @@ a situation may occur in the following scenario:
 Suppose that Python Semantic Release has been configured to use the same
 prerelease token ``"alpha"`` for all ``feature-*`` branches, and the default tag
 format ``"v{version}"``. In this case, running a pre-release from branch ``feature-1``
-will recognise that since the last release, ``1.1.0``, a **feature** has been
+will recognize that since the last release, ``1.1.0``, a **feature** has been
 introduced and therefore the next tag to be applied to ``feature-1`` will be
 ``v1.2.0-alpha.1``.
 
 However, suppose we then try to run a release against ``feature-2``. This will also
-recognise that a **feature** has been introduced against the last released version of
+recognize that a **feature** has been introduced against the last released version of
 ``v1.1.0`` and therefore will try to create the tag ``v1.2.0-alpha.1``, leading to an
 error as this tag was already created against ``feature-1``.
 
@@ -91,7 +91,7 @@ Each release group is configured as a nested mapping under the
 ``tool.semantic_release.branches`` key in ``pyproject.toml``, or the equivalent
 structure in other formats. the mapping requires a single key that is used as a
 name for the release group, which can help to identify it in log messages but has
-no effect on the behaviour of the release. For example, Python Semantic Release has
+no effect on the behavior of the release. For example, Python Semantic Release has
 only one release group by default with the name ``main``.
 
 Inside each release group, the following key-value pairs can be set:

{python_semantic_release-9.18.1 → python_semantic_release-9.19.1}/docs/strict_mode.rst

@@ -4,7 +4,7 @@ Strict Mode
 ===========
 
 Strict Mode is enabled by use of the :ref:`strict <cmd-main-option-strict>` parameter
-to the main command for Python Semantic Release. Strict Mode alters the behaviour of
+to the main command for Python Semantic Release. Strict Mode alters the behavior of
 Python Semantic Release when certain conditions are encountered that prevent Python
 Semantic Release from performing an action. Typically, this will result in a warning
 becoming an error, or a different exit code (0 vs non-zero) being produced when Python