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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.18.1
+Version: 9.19.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.18.1 → python_semantic_release-9.19.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.18.0
+    - uses: python-semantic-release/python-semantic-release@v9.18.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.18.0
+    - uses: python-semantic-release/publish-action@v9.18.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.18.0
+            uses: python-semantic-release/python-semantic-release@v9.18.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.18.0
+            uses: python-semantic-release/publish-action@v9.18.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.18.0
+    uses: python-semantic-release/python-semantic-release@v9.18.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.18.0
+     uses: python-semantic-release/python-semantic-release@v9.18.1
      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.18.1
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/docs/changelog_templates.rst

@@ -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>`
@@ -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.
 

{python_semantic_release-9.18.1 → python_semantic_release-9.19.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 ${NEW_RELEASE_TAG})*
 - :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 ${NEW_RELEASE_TAG}*
+
+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 ``${NEW_RELEASE_TAG}``. 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:
 
@@ -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.0}/docs/configuration.rst

@@ -790,7 +790,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 ${NEW_RELEASE_TAG})*
+    * ``conventional`` - :ref:`ConventionalCommitParser <commit_parser-builtin-conventional>` *(available in ${NEW_RELEASE_TAG}+)*
     * ``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 +801,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"``
 
 ----
 

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/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
 ------------------------
 

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/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.0}/pyproject.toml

@@ -6,7 +6,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-semantic-release"
-version = "9.18.1"
+version = "9.19.0"
 description = "Automatic Semantic Versioning for Python projects"
 requires-python = ">=3.8"
 license = { text = "MIT" }
@@ -436,6 +436,11 @@ match = "^(feat|fix|perf)/.+"
 prerelease = true
 prerelease_token = "alpha"
 
+[tool.semantic_release.branches.dev]
+match = ".+"
+prerelease = true
+prerelease_token = "dev"
+
 [tool.semantic_release.remote]
 type = "github"
 token = { env = "GH_TOKEN" }

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: python-semantic-release
-Version: 9.18.1
+Version: 9.19.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/src/python_semantic_release.egg-info/SOURCES.txt

@@ -59,6 +59,7 @@ src/semantic_release/cli/commands/version.py
 src/semantic_release/commit_parser/__init__.py
 src/semantic_release/commit_parser/_base.py
 src/semantic_release/commit_parser/angular.py
+src/semantic_release/commit_parser/conventional.py
 src/semantic_release/commit_parser/emoji.py
 src/semantic_release/commit_parser/scipy.py
 src/semantic_release/commit_parser/tag.py
@@ -180,7 +181,7 @@ tests/unit/semantic_release/cli/test_masking_filter.py
 tests/unit/semantic_release/cli/test_util.py
 tests/unit/semantic_release/cli/test_version.py
 tests/unit/semantic_release/commit_parser/__init__.py
-tests/unit/semantic_release/commit_parser/test_angular.py
+tests/unit/semantic_release/commit_parser/test_conventional.py
 tests/unit/semantic_release/commit_parser/test_emoji.py
 tests/unit/semantic_release/commit_parser/test_parsed_commit.py
 tests/unit/semantic_release/commit_parser/test_scipy.py

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/src/semantic_release/__init__.py

@@ -24,7 +24,7 @@ from semantic_release.version import (
     tags_and_versions,
 )
 
-__version__ = "9.18.1"
+__version__ = "9.19.0"
 
 __all__ = [
     "CommitParser",

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/src/semantic_release/cli/config.py

@@ -39,6 +39,7 @@ from semantic_release.cli.masking_filter import MaskingFilter
 from semantic_release.commit_parser import (
     AngularCommitParser,
     CommitParser,
+    ConventionalCommitParser,
     EmojiCommitParser,
     ParseResult,
     ParserOptions,
@@ -73,6 +74,7 @@ class HvcsClient(str, Enum):
 
 
 _known_commit_parsers: Dict[str, type[CommitParser]] = {
+    "conventional": ConventionalCommitParser,
     "angular": AngularCommitParser,
     "emoji": EmojiCommitParser,
     "scipy": ScipyCommitParser,
@@ -355,7 +357,7 @@ class RawConfig(BaseModel):
         env="GIT_COMMIT_AUTHOR", default=DEFAULT_COMMIT_AUTHOR
     )
     commit_message: str = COMMIT_MESSAGE
-    commit_parser: NonEmptyString = "angular"
+    commit_parser: NonEmptyString = "conventional"
     # It's up to the parser_options() method to validate these
     commit_parser_options: Dict[str, Any] = {}
     logging_use_named_masks: bool = False
@@ -414,6 +416,22 @@ class RawConfig(BaseModel):
             )
         return val
 
+    @field_validator("commit_parser", mode="after")
+    @classmethod
+    def angular_commit_parser_deprecation_warning(cls, val: str) -> str:
+        if val == "angular":
+            log.warning(
+                str.join(
+                    " ",
+                    [
+                        "The 'angular' parser is deprecated and will be removed in v11.",
+                        "The Angular parser is being renamed to the conventional commit parser,",
+                        "which is selected by switching the 'commit_parser' value to 'conventional'.",
+                    ],
+                )
+            )
+        return val
+
     @field_validator("build_command_env", mode="after")
     @classmethod
     def remove_whitespace(cls, val: list[str]) -> list[str]:
@@ -863,6 +881,7 @@ class RuntimeContext:
             changelog_excluded_commit_patterns=changelog_excluded_commit_patterns,
             # TODO: change when we have other styles per parser
             # changelog_style=changelog_style,
+            # TODO: Breaking Change v10, change to conventional
             changelog_style="angular",
             changelog_output_format=raw.changelog.default_templates.output_format,
             prerelease=branch_config.prerelease,

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/src/semantic_release/commit_parser/__init__.py

@@ -6,6 +6,10 @@ from semantic_release.commit_parser.angular import (
     AngularCommitParser,
     AngularParserOptions,
 )
+from semantic_release.commit_parser.conventional import (
+    ConventionalCommitParser,
+    ConventionalCommitParserOptions,
+)
 from semantic_release.commit_parser.emoji import (
     EmojiCommitParser,
     EmojiParserOptions,

python_semantic_release-9.19.0/src/semantic_release/commit_parser/conventional.py

@@ -0,0 +1,31 @@
+from __future__ import annotations
+
+from pydantic.dataclasses import dataclass
+
+from semantic_release.commit_parser.angular import (
+    AngularCommitParser,
+    AngularParserOptions,
+)
+
+
+@dataclass
+class ConventionalCommitParserOptions(AngularParserOptions):
+    """Options dataclass for the ConventionalCommitParser."""
+
+
+class ConventionalCommitParser(AngularCommitParser):
+    """
+    A commit parser for projects conforming to the conventional commits specification.
+
+    See https://www.conventionalcommits.org/en/v1.0.0/
+    """
+
+    # TODO: Deprecate in lieu of get_default_options()
+    parser_options = ConventionalCommitParserOptions
+
+    def __init__(self, options: ConventionalCommitParserOptions | None = None) -> None:
+        super().__init__(options)
+
+    @staticmethod
+    def get_default_options() -> ConventionalCommitParserOptions:
+        return ConventionalCommitParserOptions()

{python_semantic_release-9.18.1 → python_semantic_release-9.19.0}/tests/const.py

@@ -63,19 +63,19 @@ SUPPORTED_ISSUE_CLOSURE_PREFIXES = [
     "Implementing",
 ]
 
-ANGULAR_COMMITS_CHORE = ("ci: added a commit lint job\n",)
+CONVENTIONAL_COMMITS_CHORE = ("ci: added a commit lint job\n",)
 # Different in-scope commits that produce a certain release type
-ANGULAR_COMMITS_PATCH = (
-    *ANGULAR_COMMITS_CHORE,
+CONVENTIONAL_COMMITS_PATCH = (
+    *CONVENTIONAL_COMMITS_CHORE,
     "fix: fixed voltage in the flux capacitor\n",
 )
-ANGULAR_COMMITS_MINOR = (
-    *ANGULAR_COMMITS_PATCH,
+CONVENTIONAL_COMMITS_MINOR = (
+    *CONVENTIONAL_COMMITS_PATCH,
     "feat: last minute rush order\n",
 )
 # Take previous commits and insert a breaking change
-ANGULAR_COMMITS_MAJOR = (
-    *ANGULAR_COMMITS_MINOR,
+CONVENTIONAL_COMMITS_MAJOR = (
+    *CONVENTIONAL_COMMITS_MINOR,
     "fix!: big change\n\nBREAKING CHANGE: reworked something for previous feature\n",
 )