python-semantic-release 10.3.1__tar.gz → 10.4.0__tar.gz

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-semantic-release
-Version: 10.3.1
+Version: 10.4.0
 Summary: Automatic Semantic Versioning for Python projects
 Author-email: Rolf Erik Lekang <me@rolflekang.com>
 License: MIT
@@ -17,7 +17,7 @@ Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
-Requires-Python: >=3.8
+Requires-Python: ~=3.8
 Description-Content-Type: text/x-rst
 License-File: LICENSE
 Requires-Dist: click~=8.1.0

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/docs/concepts/commit_parsing.rst

@@ -49,6 +49,7 @@ Built-in Commit Parsers
 The following parsers are built in to Python Semantic Release:
 
 - :ref:`ConventionalCommitParser <commit_parser-builtin-conventional>`
+- :ref:`ConventionalCommitMonorepoParser <commit_parser-builtin-conventional-monorepo>` *(available in ${NEW_RELEASE_TAG}+)*
 - :ref:`AngularCommitParser <commit_parser-builtin-angular>` *(deprecated in v9.19.0)*
 - :ref:`EmojiCommitParser <commit_parser-builtin-emoji>`
 - :ref:`ScipyCommitParser <commit_parser-builtin-scipy>`
@@ -65,7 +66,7 @@ Conventional Commits Parser
 
 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:
+logic in relation to 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
@@ -127,13 +128,98 @@ logic in relation to how PSR's core features:
 
 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>`.
+:py:class:`defaults <semantic_release.commit_parser.conventional.options.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-conventional-monorepo:
+
+Conventional Commits Monorepo Parser
+""""""""""""""""""""""""""""""""""""
+
+*Introduced in ${NEW_RELEASE_TAG}*
+
+.. important::
+  In order for this parser to be effective, please review the section titled
+  :ref:`monorepos` for details on file structure, configurations, and release actions.
+
+This parser is an extension of the :ref:`commit_parser-builtin-conventional`, designed specifically
+for monorepo environments. A monorepo environment is defined as a single source control repository
+that contains multiple packages, each of which can be released independently and may have different
+version numbers.
+
+This parser introduces two new configuration options that determine which packages are affected
+by a commit. These options control whether a commit is considered for version determination,
+changelog generation, and other release actions for the relevant packages. The 2 new
+configuration options are
+:py:class:`path_filters <semantic_release.commit_parser.conventional.options_monorepo.ConventionalCommitMonorepoParserOptions.path_filters>`
+and
+:py:class:`scope_prefix <semantic_release.commit_parser.conventional.options_monorepo.ConventionalCommitMonorepoParserOptions.scope_prefix>`.
+
+**Features**:
+
+- **Package Specific Commit Filtering**: For monorepo support, this parser uses 2 filtering rules
+  to determine if a commit should be considered for a specific package. The first rule is based on
+  file paths that are changed in the commit and the second rule is based on the optional scope
+  prefix defined in the commit message. If either rule matches, then the commit is considered
+  relevant to that package and will be used in version determination, changelog generation, etc,
+  for that package. If neither rule matches, then the commit is ignored for that package. File
+  path filtering rules are applied first and are the primary way to determine package relevance. The
+  :py:class:`path_filters <semantic_release.commit_parser.conventional.options_monorepo.ConventionalCommitMonorepoParserOptions.path_filters>`
+  option allows for specifying a list of file path patterns and will also support negated patterns
+  to ignore specific paths that otherwise would be selected from the file glob pattern.  Negated
+  patterns are defined by prefixing the pattern with an exclamation point (``!``). File path
+  filtering is quite effective by itself but to handle the edge cases, the parser has the
+  :py:class:`scope_prefix <semantic_release.commit_parser.conventional.options_monorepo.ConventionalCommitMonorepoParserOptions.scope_prefix>`
+  configuration option to allow the developer to specifically define when the commit is relevant
+  to the package. In monorepo setups, there are often shared files between packages (generally at
+  the root project level) that are modified occasionally but not always relevant to the package
+  being released. Since you do not want to define this path in the package configuration as it may
+  not be relevant to the release, then this parser will look for a match with the scope prefix.
+  The scope prefix is a regular expression that is used to match the text inside the scope field
+  of a Conventional Commit. The scope prefix is optional and is used only if file path filtering
+  does not match. Commits that have matching files in the commit will be considered relevant to
+  the package **regardless** if a scope prefix exists or if it matches.
+
+- **Version Bump Determination**: Once package-specific commit filtering is applied, the relevant
+  commits are passed to the Conventional Commits Parser for evaluation and then used for version
+  bump determination. See :ref:`commit_parser-builtin-conventional` for details.
+
+- **Changelog Generation**: Once package-specific commit filtering is applied, the relevant
+  commits are passed to the Conventional Commits Parser for evaluation and then used for
+  changelog generation. See :ref:`commit_parser-builtin-conventional` for details.
+
+- **Pull/Merge Request Identifier Detection**: Once package-specific commit filtering is applied,
+  the relevant commits are passed to the Conventional Commits Parser for pull/merge request
+  identifier detection. See :ref:`commit_parser-builtin-linked_merge_request_detection` for details.
+
+- **Linked Issue Identifier Detection**: Once package-specific commit filtering is applied, the
+  relevant commits are passed to the Conventional Commits Parser for linked issue identifier
+  detection. See :ref:`commit_parser-builtin-issue_number_detection` for details.
+
+- **Squash Commit Evaluation**: Squashed commits are separated out into individual commits with
+  the same set of changed files **BEFORE** the package-specific commit filtering is applied.
+  Each pseudo-commit is then subjected to the same filtering rules as regular commits. See
+  :ref:`commit_parser-builtin-squash_commit_evaluation` for details.
+
+- **Release Notice Footer Detection**: Once package-specific commit filtering is applied, the
+  relevant commits are passed to the Conventional Commits Parser for release notice footer
+  detection. See :ref:`commit_parser-builtin-release_notice_footer_detection` for details.
+
+**Limitations**:
+
+- ``revert`` commit type is NOT supported, see :ref:`commit_parser-builtin-conventional`'s
+  limitations for details.
+
+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.options_monorepo.ConventionalCommitMonorepoParserOptions>`.
+
+----
+
 .. _commit_parser-builtin-angular:
 
 Angular Commit Parser

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/docs/configuration/automatic-releases/github-actions.rst

@@ -933,14 +933,14 @@ 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@v10.3.1
+            uses: python-semantic-release/python-semantic-release@v10.4.0
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
               git_committer_name: "github-actions"
               git_committer_email: "actions@users.noreply.github.com"
 
           - name: Publish | Upload to GitHub Release Assets
-            uses: python-semantic-release/publish-action@v10.3.1
+            uses: python-semantic-release/publish-action@v10.4.0
             if: steps.release.outputs.released == 'true'
             with:
               github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -1039,7 +1039,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@v10.3.1
+    uses: python-semantic-release/python-semantic-release@v10.4.0
     with:
       github_token: ${{ secrets.GITHUB_TOKEN }}
       force: patch
@@ -1098,14 +1098,14 @@ Publish Action.
 
         - name: Release submodule 1
           id: release-submod-1
-          uses: python-semantic-release/python-semantic-release@v10.3.1
+          uses: python-semantic-release/python-semantic-release@v10.4.0
           with:
             directory: ${{ env.SUBMODULE_1_DIR }}
             github_token: ${{ secrets.GITHUB_TOKEN }}
 
         - name: Release submodule 2
           id: release-submod-2
-          uses: python-semantic-release/python-semantic-release@v10.3.1
+          uses: python-semantic-release/python-semantic-release@v10.4.0
           with:
             directory: ${{ env.SUBMODULE_2_DIR }}
             github_token: ${{ secrets.GITHUB_TOKEN }}
@@ -1117,7 +1117,7 @@ Publish Action.
         # ------------------------------------------------------------------- #
 
         - name: Publish | Upload package 1 to GitHub Release Assets
-          uses: python-semantic-release/publish-action@v10.3.1
+          uses: python-semantic-release/publish-action@v10.4.0
           if: steps.release-submod-1.outputs.released == 'true'
           with:
             directory: ${{ env.SUBMODULE_1_DIR }}
@@ -1125,7 +1125,7 @@ Publish Action.
             tag: ${{ steps.release-submod-1.outputs.tag }}
 
         - name: Publish | Upload package 2 to GitHub Release Assets
-          uses: python-semantic-release/publish-action@v10.3.1
+          uses: python-semantic-release/publish-action@v10.4.0
           if: steps.release-submod-2.outputs.released == 'true'
           with:
             directory: ${{ env.SUBMODULE_2_DIR }}

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/docs/configuration/configuration-guides/index.rst

@@ -11,4 +11,5 @@ more specific configurations.
 .. toctree::
     :maxdepth: 1
 
+    Monorepos <monorepos>
     UV Project Setup <uv_integration>

python_semantic_release-10.4.0/docs/configuration/configuration-guides/monorepos.rst

@@ -0,0 +1,358 @@
+.. _monorepos:
+
+Releasing Packages from a Monorepo
+==================================
+
+
+A monorepo (mono-repository) is a software development strategy where code for multiple projects is stored in a single source control system. This approach streamlines and consolidates configuration, but introduces complexities when using automated tools like Python Semantic Release (PSR).
+
+Previously, PSR offered limited compatibility with monorepos. As of ${NEW_RELEASE_TAG}, PSR introduces the :ref:`commit_parser-builtin-conventional-monorepo`, designed specifically for monorepo environments. To fully leverage this new parser, you must configure your monorepo as described below.
+
+.. _monorepos-config:
+
+Configuring PSR
+---------------
+
+.. _monorepos-config-example_simple:
+
+Example: Simple
+"""""""""""""""
+
+
+**Directory Structure**: PSR does not yet support a single, workspace-level configuration definition. This means each package in the monorepo requires its own PSR configuration file. A compatible and common monorepo file structure looks like:
+
+.. code::
+
+    project/
+    ├── .git/
+    ├── .venv/
+    ├── packages/
+    │   ├── pkg1/
+    │   │   ├── docs/
+    │   │   │   └── source/
+    │   │   │       ├── conf.py
+    │   │   │       └── index.rst
+    │   │   │
+    │   │   ├── src/
+    │   │   │   └── pkg1/
+    │   │   │       ├── __init__.py
+    │   │   │       ├── __main__.py
+    │   │   │       └── py.typed
+    │   │   │
+    │   │   ├── CHANGELOG.md
+    │   │   ├── README.md
+    │   │   └── pyproject.toml             <-- PSR Configuration for Package 1
+    │   │
+    │   └── pkg2/
+    │       ├── docs/
+    │       │   └── source/
+    │       │       ├── conf.py
+    │       │       └── index.rst
+    │       ├── src/
+    │       │   └── pkg2/
+    │       │       ├── __init__.py
+    │       │       ├── __main__.py
+    │       │       └── py.typed
+    │       │
+    │       ├── CHANGELOG.md
+    │       ├── README.md
+    │       └── pyproject.toml             <-- PSR Configuration for Package 2
+    │
+    ├── .gitignore
+    └── README.md
+
+
+This is the most basic monorepo structure, where each package is self-contained with its own configuration files, documentation, and CHANGELOG files. To release a package, change your current working directory to the package directory and execute PSR's :ref:`cmd-version`. PSR will automatically read the package's ``pyproject.toml``, looking for the ``[tool.semantic_release]`` section to determine the package's versioning and release configuration, then search up the file tree to find the Git repository.
+
+Because there is no workspace-level configuration, you must duplicate any common PSR configuration in each package's configuration file. Customize each configuration for each package to specify how PSR should distinguish between commits.
+
+With the example file structure above, here is an example configuration file for each package:
+
+.. code-block:: toml
+
+    # FILE: pkg1/pyproject.toml
+    [project]
+    name = "pkg1"
+    version = "1.0.0"
+
+    [tool.semantic_release]
+    commit_parser = "conventional-monorepo"
+    commit_message = """\
+    chore(release): pkg1@{version}`
+
+    Automatically generated by python-semantic-release
+    """
+    tag_format = "pkg1-v{version}"
+    version_toml = ["pyproject.toml:project.version"]
+
+    [tool.semantic_release.commit_parser_options]
+    path_filters = ["."]
+    scope_prefix = "pkg1-"
+
+.. code-block:: toml
+
+    # FILE: pkg2/pyproject.toml
+    [project]
+    name = "pkg2"
+    version = "1.0.0"
+
+    [tool.semantic_release]
+    commit_parser = "conventional-monorepo"
+    commit_message = """\
+    chore(release): pkg2@{version}`
+
+    Automatically generated by python-semantic-release
+    """
+    tag_format = "pkg2-v{version}"
+    version_toml = ["pyproject.toml:project.version"]
+
+    [tool.semantic_release.commit_parser_options]
+    path_filters = ["."]
+    scope_prefix = "pkg2-"
+
+
+These are the minimum configuration options required for each package. Note the use of :ref:`config-tag_format` to distinguish tags between packages. The commit parser options are specific to the new :ref:`commit_parser-builtin-conventional-monorepo` and play a significant role in identifying which commits are relevant to each package. Since you are expected to change directories to each package before releasing, file paths in each configuration file should be relative to the package directory.
+
+Each package also defines a slightly different :ref:`config-commit_message` to reflect the package name in each message. This helps clarify which release number is being updated in the commit history.
+
+
+Release Steps
+'''''''''''''
+
+Given the following Git history of a monorepo using a GitHub Flow branching strategy (without CI/CD):
+
+.. image:: ./monorepos-ex-easy-before-release.png
+
+To manually release both packages, run:
+
+.. code-block:: bash
+
+    cd packages/pkg1
+    semantic-release version
+    # 1.0.1 (tag: pkg1-v1.0.1)
+
+    cd ../pkg2
+    semantic-release version
+    # 1.1.0 (tag: pkg2-v1.1.0)
+
+After releasing both packages, the resulting Git history will look like:
+
+.. image:: ./monorepos-ex-easy-post-release.png
+
+.. seealso::
+
+    - :ref:`GitHub Actions with Monorepos <gh_actions-monorepo>`
+
+
+Considerations
+''''''''''''''
+
+1. **Custom Changelogs**: Managing changelogs can be tricky depending on where you want to write the changelog files. In this simple example, the changelog is located within each package directory, and the changelog template does not have any package-specific formatting or naming convention. You can use one shared template directory at the root of the project and configure each package to point to the shared template directory.
+
+.. code-block:: toml
+
+    # FILE: pkg1/pyproject.toml
+    [tool.semantic_release]
+    template_dir = "../../config/release-templates"
+
+.. code-block:: toml
+
+    # FILE: pkg2/pyproject.toml
+    [tool.semantic_release]
+    template_dir = "../../config/release-templates"
+
+.. code::
+
+    project/
+    ├── .git/
+    ├── config/
+    │   └── release-templates/
+    │       ├── CHANGELOG.md.j2
+    │       └── .release_notes.md.j2
+    ├── packages/
+    │   ├── pkg1/
+    │   │   ├── CHANGELOG.md
+    │   │   └── pyproject.toml
+    │   │
+    │   └── pkg2/
+    │       ├── CHANGELOG.md
+    │       └── pyproject.toml
+    │
+    ├── .gitignore
+    └── README.md
+
+.. seealso::
+
+    - For situations with more complex documentation needs, see our :ref:`Advanced Example <monorepos-config-example_advanced>`.
+
+
+2. **Package Prereleases**: Creating pre-releases is possible, but it is recommended to use package-prefixed branch names to avoid collisions between packages. For example, to enable alpha pre-releases for new features in both packages, use the following configuration:
+
+.. code-block:: toml
+
+    # FILE: pkg1/pyproject.toml
+    [tool.semantic_release.branches.alpha-release]
+    match = "^pkg1/feat/.+"                       # <-- note pkg1 prefix
+    prerelease = true
+    prerelease_token = "alpha"
+
+.. code-block:: toml
+
+    # FILE: pkg2/pyproject.toml
+    [tool.semantic_release.branches.alpha-release]
+    match = "^pkg2/feat/.+"                       # <-- note pkg2 prefix
+    prerelease = true
+    prerelease_token = "alpha"
+
+----
+
+.. _monorepos-config-example_advanced:
+
+Example: Advanced
+"""""""""""""""""
+
+
+If you want to consolidate documentation into a single top-level directory, the setup becomes more complex. In this example, there is a common documentation folder at the top level, and each package has its own subfolder within the documentation folder.
+
+Due to naming conventions, PSR cannot automatically accomplish this with its default changelog templates. For this scenario, you must copy the internal PSR templates into a custom directory (even if you do not modify them) and add custom scripting to prepare for each release.
+
+The directory structure looks like:
+
+.. code::
+
+    project/
+    ├── .git/
+    ├── docs/
+    │   ├── source/
+    │   │   ├── pkg1/
+    │   │   │   ├── changelog.md
+    │   │   │   └── README.md
+    │   │   ├── pkg2/
+    │   │   │   ├── changelog.md
+    │   │   │   └── README.md
+    │   │   └── index.rst
+    │   │
+    │   └── templates/
+    │       ├── .base_changelog_template/
+    │       │   ├── components/
+    │       │   │   ├── changelog_header.md.j2
+    │       │   │   ├── changelog_init.md.j2
+    │       │   │   ├── changelog_update.md.j2
+    │       │   │   ├── changes.md.j2
+    │       │   │   ├── first_release.md.j2
+    │       │   │   ├── macros.md.j2
+    │       │   │   ├── unreleased_changes.md.j2
+    │       │   │   └── versioned_changes.md.j2
+    │       │   └── changelog.md.j2
+    │       ├── .gitignore
+    │       └── .release_notes.md.j2
+    │
+    ├── packages/
+    │   ├── pkg1/
+    │   │   ├── src/
+    │   │   │   └── pkg1/
+    │   │   │       ├── __init__.py
+    │   │   │       └── __main__.py
+    │   │   └── pyproject.toml
+    │   │
+    │   └── pkg2/
+    │       ├── src/
+    │       │   └── pkg2/
+    │       │       ├── __init__.py
+    │       │       └── __main__.py
+    │       └── pyproject.toml
+    │
+    └── scripts/
+        ├── release-pkg1.sh
+        └── release-pkg2.sh
+
+
+Each package should point to the ``docs/templates/`` directory to use a common release notes template. PSR ignores hidden files and directories when searching for template files to create, allowing you to hide shared templates in the directory for use in your release setup script.
+
+Here is our configuration file for package 1 (package 2 is similarly defined):
+
+.. code-block:: toml
+
+    # FILE: pkg1/pyproject.toml
+    [project]
+    name = "pkg1"
+    version = "1.0.0"
+
+    [tool.semantic_release]
+    commit_parser = "conventional-monorepo"
+    commit_message = """\
+    chore(release): Release `pkg1@{version}`
+
+    Automatically generated by python-semantic-release
+    """
+    tag_format = "pkg1-v{version}"
+    version_toml = ["pyproject.toml:project.version"]
+
+    [tool.semantic_release.commit_parser_options]
+    path_filters = [
+        ".",
+        "../../../docs/source/pkg1/**",
+    ]
+    scope_prefix = "pkg1-"
+
+    [tool.semantic_release.changelog]
+    template_dir = "../../../docs/templates"
+    mode = "update"
+    exclude_commit_patterns = [
+        '''^chore(?:\([^)]*?\))?: .+''',
+        '''^ci(?:\([^)]*?\))?: .+''',
+        '''^refactor(?:\([^)]*?\))?: .+''',
+        '''^style(?:\([^)]*?\))?: .+''',
+        '''^test(?:\([^)]*?\))?: .+''',
+        '''^Initial [Cc]ommit''',
+    ]
+
+    [tool.semantic_release.changelog.default_templates]
+    # To enable update mode: this value must set here because the default is not the
+    # same as the default in the other package & must be the final destination filename
+    # for the changelog relative to this file
+    changelog_file = "../../../docs/source/pkg1/changelog.md"
+
+
+Note: In this configuration, we added path filters for additional documentation files related to the package so that the changelog will include documentation changes as well.
+
+
+Next, define a release script to set up the common changelog templates in the correct directory format so PSR will create the desired files at the proper locations. Following the :ref:`changelog-templates-template-rendering` reference, you must define the folder structure from the root of the project within the templates directory so PSR will properly lay down the files across the repository. The script cleans up any previous templates, dynamically creates the necessary directories, and copies over the shared templates into a package-named directory. Now you are prepared to run PSR for a release of ``pkg1``.
+
+.. code-block:: bash
+
+    #!/bin/bash
+    # FILE: scripts/release-pkg1.sh
+
+    set -euo pipefail
+
+    PROJECT_ROOT="$(dirname "$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")")"
+    VIRTUAL_ENV="$PROJECT_ROOT/.venv"
+
+    PACKAGE_NAME="pkg1"
+
+    cd "$PROJECT_ROOT" || exit 1
+
+    # Setup documentation template
+    pushd "docs/templates" >/dev/null || exit 1
+
+    rm -rf docs/
+    mkdir -p "docs/source/"
+    cp -r .base_changelog_template/ "docs/source/$PACKAGE_NAME"
+
+    popd >/dev/null || exit 1
+
+    # Release the package
+    pushd "packages/$PACKAGE_NAME" >/dev/null || exit 1
+
+    printf '%s\n' "Releasing $PACKAGE_NAME..."
+    "$VIRTUAL_ENV/bin/semantic-release" -v version --no-push
+
+    popd >/dev/null || exit 1
+
+
+That's it! This example demonstrates how to set up a monorepo with shared changelog templates and a consolidated documentation folder for multiple packages.
+
+.. seealso::
+
+    - Advanced Example Monorepo: `codejedi365/psr-monorepo-poweralpha <https://github.com/codejedi365/psr-monorepo-poweralpha>`_

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/docs/configuration/configuration-guides/uv_integration.rst

@@ -176,7 +176,7 @@ look like this:
           id: version
           env:
             GH_TOKEN: "none"
-          run: uv run semantic-release -v version --no-commit --no-tag
+          run: uv run semantic-release -v version --no-changelog --no-commit --no-tag
 
         - name: Upload | Distribution Artifacts
           if: ${{ steps.version.outputs.released == 'true' }}

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/docs/configuration/configuration.rst

@@ -796,6 +796,7 @@ within the Git repository.
 Built-in parsers:
     * ``angular`` - :ref:`AngularCommitParser <commit_parser-builtin-angular>` *(deprecated in v9.19.0)*
     * ``conventional`` - :ref:`ConventionalCommitParser <commit_parser-builtin-conventional>` *(available in v9.19.0+)*
+    * ``conventional-monorepo`` - :ref:`ConventionalCommitMonorepoParser <commit_parser-builtin-conventional-monorepo>` *(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)*

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/pyproject.toml

@@ -6,9 +6,9 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-semantic-release"
-version = "10.3.1"
+version = "10.4.0"
 description = "Automatic Semantic Versioning for Python projects"
-requires-python = ">=3.8"
+requires-python = "~= 3.8"
 license = { text = "MIT" }
 classifiers = [
   "Programming Language :: Python",

{python_semantic_release-10.3.1 → python_semantic_release-10.4.0}/src/python_semantic_release.egg-info/SOURCES.txt

@@ -21,6 +21,9 @@ docs/configuration/automatic-releases/github-actions.rst
 docs/configuration/automatic-releases/index.rst
 docs/configuration/automatic-releases/travis.rst
 docs/configuration/configuration-guides/index.rst
+docs/configuration/configuration-guides/monorepos-ex-easy-before-release.png
+docs/configuration/configuration-guides/monorepos-ex-easy-post-release.png
+docs/configuration/configuration-guides/monorepos.rst
 docs/configuration/configuration-guides/uv_integration.rst
 docs/contributing/contributing_guide.rst
 docs/contributing/index.rst
@@ -60,12 +63,16 @@ 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
 src/semantic_release/commit_parser/token.py
 src/semantic_release/commit_parser/util.py
+src/semantic_release/commit_parser/conventional/__init__.py
+src/semantic_release/commit_parser/conventional/options.py
+src/semantic_release/commit_parser/conventional/options_monorepo.py
+src/semantic_release/commit_parser/conventional/parser.py
+src/semantic_release/commit_parser/conventional/parser_monorepo.py
 src/semantic_release/data/templates/conventional/md/.release_notes.md.j2
 src/semantic_release/data/templates/conventional/md/CHANGELOG.md.j2
 src/semantic_release/data/templates/conventional/md/.components/changelog_header.md.j2
@@ -143,16 +150,29 @@ tests/e2e/cmd_version/bump_version/github_flow/__init__.py
 tests/e2e/cmd_version/bump_version/github_flow/test_repo_1_channel.py
 tests/e2e/cmd_version/bump_version/github_flow/test_repo_1_channel_branch_update_merge.py
 tests/e2e/cmd_version/bump_version/github_flow/test_repo_2_channels.py
+tests/e2e/cmd_version/bump_version/github_flow_monorepo/__init__.py
+tests/e2e/cmd_version/bump_version/github_flow_monorepo/test_monorepo_1_channel.py
+tests/e2e/cmd_version/bump_version/github_flow_monorepo/test_monorepo_2_channels.py
 tests/e2e/cmd_version/bump_version/trunk_based_dev/__init__.py
 tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_trunk.py
 tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_trunk_dual_version_support.py
 tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_trunk_dual_version_support_w_prereleases.py
 tests/e2e/cmd_version/bump_version/trunk_based_dev/test_repo_trunk_w_prereleases.py
+tests/e2e/cmd_version/bump_version/trunk_based_dev_monorepo/__init__.py
+tests/e2e/cmd_version/bump_version/trunk_based_dev_monorepo/test_monorepo_trunk.py
 tests/fixtures/__init__.py
 tests/fixtures/commit_parsers.py
 tests/fixtures/example_project.py
 tests/fixtures/git_repo.py
 tests/fixtures/scipy.py
+tests/fixtures/monorepos/__init__.py
+tests/fixtures/monorepos/example_monorepo.py
+tests/fixtures/monorepos/git_monorepo.py
+tests/fixtures/monorepos/github_flow/__init__.py
+tests/fixtures/monorepos/github_flow/monorepo_w_default_release.py
+tests/fixtures/monorepos/github_flow/monorepo_w_release_channels.py
+tests/fixtures/monorepos/trunk_based_dev/__init__.py
+tests/fixtures/monorepos/trunk_based_dev/monorepo_w_tags.py
 tests/fixtures/repos/__init__.py
 tests/fixtures/repos/repo_initial_commit.py
 tests/fixtures/repos/git_flow/__init__.py