python-semantic-release 9.16.1__tar.gz → 9.18.0__tar.gz

{python_semantic_release-9.16.1/src/python_semantic_release.egg-info → python_semantic_release-9.18.0}/PKG-INFO

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

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/docs/automatic-releases/github-actions.rst

@@ -337,7 +337,7 @@ before the :ref:`version <cmd-version>` subcommand.
 
   .. code:: yaml
 
-    - uses: python-semantic-release/python-semantic-release@v9.16.0
+    - uses: python-semantic-release/python-semantic-release@v9.17.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.16.0
+    - uses: python-semantic-release/publish-action@v9.17.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.16.0
+            uses: python-semantic-release/python-semantic-release@v9.17.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.16.0
+            uses: python-semantic-release/publish-action@v9.17.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.16.0
+    uses: python-semantic-release/python-semantic-release@v9.17.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.16.0
+     uses: python-semantic-release/python-semantic-release@v9.17.0
      with:
        directory: ./project1
        github_token: ${{ secrets.GITHUB_TOKEN }}
 
    - name: Release Project 2
-     uses: python-semantic-release/python-semantic-release@v9.16.0
+     uses: python-semantic-release/python-semantic-release@v9.17.0
      with:
        directory: ./project2
        github_token: ${{ secrets.GITHUB_TOKEN }}

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/docs/changelog_templates.rst

@@ -246,6 +246,11 @@ Configuration Examples
           '''Merged? .*''',
         ]
 
+If identified or supported by the parser, the default changelog templates will include
+a separate section of breaking changes and additional release information. Refer to the
+:ref:`commit parsing <commit-parsing>` section to see how to write commit messages that
+will be properly parsed and displayed in these sections.
+
 
 .. _changelog-templates-default_release_notes:
 
@@ -260,16 +265,37 @@ default built-in template out-of-the-box for generating release notes.
 
 The difference between the changelog and release notes is that the release notes
 only contain the changes for the current release. Due to the modularity of the
-PSR templates, the format is identical to an individual version of the default
-changelog.
+PSR templates, the format is similar to an individual version of the default
+changelog but may include other version specific information.
 
 At this time, the default template for version release notes is only available
 in Markdown format for all VCS types.
 
+If you want to review what the default release notes look like you can use the
+following command to print the release notes to the console (remove any configuration
+for defining a custom template directory):
+
+.. code:: console
+
+    # Create a current tag
+    git tag v1.0.0
+    semantic-release --noop changelog --post-to-release-tag v1.0.0
+
+The default template provided by PSR will respect the
+:ref:`<config-changelog-default_templates-mask_initial_release>` setting and
+will also add a comparison link to the previous release if one exists without
+customization.
+
+As of ``${NEW_RELEASE_TAG}``, the default release notes will also include a statement to
+declare which license the project was released under. PSR determines which license
+to declare based on the value of ``project.license-expression`` in the ``pyproject.toml``
+file as defined in the `PEP 639`_ specification.
+
 .. seealso::
     - To personalize your release notes, see the
       :ref:`changelog-templates-custom_release_notes` section.
 
+.. _PEP 639: https://peps.python.org/pep-0639/
 
 .. _changelog-templates-template-rendering:
 
@@ -658,6 +684,45 @@ The filters provided vary based on the VCS configured and available features:
           )
       }}
 
+* ``create_pypi_url(package_name: str, version: str = "")``: given a package name and an optional
+  version, return a URL to the PyPI page for the package. If a version is provided, the URL will
+  point to the specific version page. If no version is provided, the URL will point to the package
+  page.
+
+  *Introduced in ${NEW_RELEASE_TAG}.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "example-package" | create_pypi_url }}
+      {{ "example-package" | create_pypi_url("1.0.0") }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      https://pypi.org/project/example-package
+      https://pypi.org/project/example-package/1.0.0
+
+* ``create_release_url (Callable[[TagStr], UrlStr])``: given a tag, return a URL to the release
+  page on the remote vcs. This filter is useful when you want to link to the release page on the
+  remote vcs.
+
+  *Introduced in ${NEW_RELEASE_TAG}.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "v1.0.0" | create_release_url }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      https://example.com/example/repo/releases/tag/v1.0.0
+
 * ``create_server_url (Callable[[PathStr, AuthStr | None, QueryStr | None, FragmentStr | None], UrlStr])``:
   when given a path, prepend the configured vcs server host and url scheme.  Optionally you
   can provide, a auth string, a query string or a url fragment to be normalized into the
@@ -817,6 +882,29 @@ The filters provided vary based on the VCS configured and available features:
 
       [#29](https://example.com/example/repo/pull/29)
 
+* ``format_w_official_vcs_name (Callable[[str], str])``: given a format string, insert
+  the official VCS type name into the string and return. This filter is useful when you want to
+  display the proper name of the VCS type in a changelog or release notes. The filter supports
+  three different replace formats: ``%s``, ``{}``, and ``{vcs_name}``.
+
+  *Introduced in ${NEW_RELEASE_TAG}.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ "%s Releases" | format_w_official_vcs_name }}
+      {{ "{} Releases" | format_w_official_vcs_name }}
+      {{ "{vcs_name} Releases" | format_w_official_vcs_name }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+      GitHub Releases
+      GitHub Releases
+      GitHub Releases
+
 * ``read_file (Callable[[str], str])``: given a file path, read the file and
   return the contents as a string. This function was added specifically to
   enable the changelog update feature where it would load the existing changelog
@@ -831,22 +919,51 @@ The filters provided vary based on the VCS configured and available features:
       {% set prev_changelog_contents = prev_changelog_file | read_file | safe %}
 
 
+* ``sort_numerically (Callable[[Iterable[str], bool], list[str]])``: given a
+  sequence of strings with possibly some non-number characters as a prefix or suffix,
+  sort the strings as if they were just numbers from lowest to highest. This filter
+  is useful when you want to sort issue numbers or other strings that have a numeric
+  component in them but cannot be cast to a number directly to sort them. If you want
+  to sort the strings in reverse order, you can pass a boolean value of ``True`` as the
+  second argument.
+
+  *Introduced in v9.16.0.*
+
+  **Example Usage:**
+
+  .. code:: jinja
+
+      {{ ["#222", "#1023", "#444"] | sort_numerically }}
+      {{ ["#222", "#1023", "#444"] | sort_numerically(True) }}
+
+  **Markdown Output:**
+
+  .. code:: markdown
+
+        ['#222', '#444', '#1023']
+        ['#1023', '#444', '#222']
+
+
 Availability of the documented filters can be found in the table below:
 
-======================  =========  =====  ======  ======
-**filter - hvcs_type**  bitbucket  gitea  github  gitlab
-======================  =========  =====  ======  ======
-autofit_text_width         ✅       ✅      ✅      ✅
-convert_md_to_rst          ✅       ✅      ✅      ✅
-create_server_url          ✅       ✅      ✅      ✅
-create_repo_url            ✅       ✅      ✅      ✅
-commit_hash_url            ✅       ✅      ✅      ✅
-compare_url                ✅       ❌      ✅      ✅
-issue_url                  ❌       ✅      ✅      ✅
-merge_request_url          ❌       ❌      ❌      ✅
-pull_request_url           ✅       ✅      ✅      ✅
-read_file                  ✅       ✅      ✅      ✅
-======================  =========  =====  ======  ======
+==========================  =========  =====  ======  ======
+**filter - hvcs_type**      bitbucket  gitea  github  gitlab
+==========================  =========  =====  ======  ======
+autofit_text_width             ✅       ✅      ✅      ✅
+convert_md_to_rst              ✅       ✅      ✅      ✅
+create_pypi_url                ✅       ✅      ✅      ✅
+create_server_url              ✅       ✅      ✅      ✅
+create_release_url             ❌       ✅      ✅      ✅
+create_repo_url                ✅       ✅      ✅      ✅
+commit_hash_url                ✅       ✅      ✅      ✅
+compare_url                    ✅       ❌      ✅      ✅
+format_w_official_vcs_name     ✅       ✅      ✅      ✅
+issue_url                      ❌       ✅      ✅      ✅
+merge_request_url              ❌       ❌      ❌      ✅
+pull_request_url               ✅       ✅      ✅      ✅
+read_file                      ✅       ✅      ✅      ✅
+sort_numerically               ✅       ✅      ✅      ✅
+==========================  =========  =====  ======  ======
 
 .. seealso::
    * `Filters <https://jinja.palletsprojects.com/en/3.1.x/templates/#filters>`_

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/docs/commit_parsing.rst

@@ -108,13 +108,19 @@ logic in relation to how PSR's core features:
   message. If no issue numbers are found, the parser will return an empty tuple. *Feature
   available in v9.15.0+.*
 
-**Limitations:**
+- **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. *Feature available in
+  v9.17.0+.*
 
-- Squash commits are not currently supported. This means that the level bump for a squash
-  commit is only determined by the subject line of the squash commit. Our default changelog
-  template currently writes out the entire commit message body in the changelog in order to
-  provide the full detail of the changes. Track the implementation of this feature with
-  the issues `#733`_, `#1085`_, and `PR#1112`_.
+- **Release Notice Footer Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-release_notice_footer_detection`, which is a custom extension
+  to traditional `Angular Commit Style Guidelines`_ to use the ``NOTICE`` keyword as a git
+  footer to document additional release information that is not considered a breaking change.
+  *Feature available in ${NEW_RELEASE_TAG}+.*
+
+**Limitations**:
 
 - Commits with the ``revert`` type are not currently supported. Track the implementation
   of this feature in the issue `#402`_.
@@ -179,6 +185,17 @@ how PSR's core features:
   enabled by setting the configuration option ``commit_parser_options.parse_linked_issues``
   to ``true``. *Feature available in v9.15.0+.*
 
+- **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. *Feature available in
+  v9.17.0+.*
+
+- **Release Notice Footer Detection**: This parser implements PSR's
+  :ref:`commit_parser-builtin-release_notice_footer_detection`, which is a custom extension
+  that uses the ``NOTICE`` keyword as a git footer to document additional release information
+  that is not considered a breaking change. *Feature available in ${NEW_RELEASE_TAG}+.*
+
 If no commit parser options are provided via the configuration, the parser will use PSR's
 built-in :py:class:`defaults <semantic_release.commit_parser.emoji.EmojiParserOptions>`.
 
@@ -304,6 +321,99 @@ return an empty tuple.
 
 ----
 
+.. _commit_parser-builtin-release_notice_footer_detection:
+
+Common Release Notice Footer Detection
+""""""""""""""""""""""""""""""""""""""
+
+*Introduced in ${NEW_RELEASE_TAG}**
+
+All of the PSR built-in parsers implement common release notice footer detection logic
+to identify and extract a ``NOTICE`` git trailer that documents any additional release
+information the developer wants to provide to the software consumer. The idea extends
+from the concept of the ``BREAKING CHANGE:`` git trailer to document any breaking change
+descriptions but the ``NOTICE`` trailer is intended to document any information that is
+below the threshold of a breaking change while still important for the software consumer
+to be aware of. Common uses would be to provide deprecation warnings or more detailed
+change usage information for that release. Parsers will collapse single newlines after
+the ``NOTICE`` trailer into a single line paragraph. Commits may have more than one
+``NOTICE`` trailer in a single commit message. Each
+:py:class:`ParsedCommit <semantic_release.commit_parser.token.ParsedCommit>` will have
+a ``release_notices`` attribute that is a tuple of string paragraphs to identify each
+release notice.
+
+In the default changelog and release notes template, these release notices will be
+formatted into their own section called **ADDITIONAL RELEASE INFORMATION**. Each will
+include any commit scope defined and each release notice in alphabetical order.
+
+----
+
+.. _commit_parser-builtin-squash_commit_evaluation:
+
+Common Squash Commit Evaluation
+"""""""""""""""""""""""""""""""
+
+*Introduced in v9.17.0*
+
+All of the PSR built-in parsers implement common squash commit evaluation logic to identify
+and extract individual commit messages from a single squashed commit. The parsers will
+look for common squash commit delimiters and multiple matches of the commit message
+format to identify each individual commit message that was squashed. The parsers will
+return a list containing each commit message as a separate commit object. Squashed commits
+will be evaluated individually for both the level bump and changelog generation. If no
+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
+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.
+
+**Example**:
+
+*The following example will extract three separate commit messages from a single GitHub
+formatted squash commit message of conventional commit style:*
+
+.. code-block:: text
+
+    feat(config): add new config option (#123)
+
+    * refactor(config): change the implementation of config loading
+
+    * 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:
+
+.. code-block:: markdown
+
+    ## Features
+
+    - **config**: add new config option (#123)
+
+    ## Documentation
+
+    - **configuration**: defined new config option for the project (#123)
+
+    ## Refactoring
+
+    - **config**: change the implementation of config loading (#123)
+
+Merge request numbers and commit hash values will be the same across all extracted
+commits. Additionally, any :ref:`config-changelog-exclude_commit_patterns` will be
+applied individually to each extracted commit so if you are have an exclusion match
+for ignoring ``refactor`` commits, the second commit in the example above would be
+excluded from the changelog.
+
+.. important::
+  When squash commit evaluation is enabled, if you squashed a higher level bump commit
+  into the body of a lower level bump commit, the higher level bump commit will be
+  evaluated as the level bump for the entire squashed commit. This includes breaking
+  change descriptions.
+
+----
+
 .. _commit_parser-builtin-customization:
 
 Customization
@@ -429,28 +539,23 @@ available.
 .. _catching exceptions in Python is slower: https://docs.python.org/3/faq/design.html#how-fast-are-exceptions
 .. _namedtuple: https://docs.python.org/3/library/typing.html#typing.NamedTuple
 
-.. _commit-parsing-parser-options:
+.. _commit_parser-parser-options:
 
 Parser Options
 """"""""""""""
 
-To provide options to the commit parser which is configured in the :ref:`configuration file
-<configuration>`, Python Semantic Release includes a
-:py:class:`ParserOptions <semantic_release.commit_parser._base.ParserOptions>`
-class. Each parser built into Python Semantic Release has a corresponding "options" class, which
-subclasses :py:class:`ParserOptions <semantic_release.commit_parser._base.ParserOptions>`.
-
-The configuration in :ref:`commit_parser_options <config-commit_parser_options>` is passed to the
-"options" class which is specified by the configured :ref:`commit_parser <config-commit_parser>` -
-more information on how this is specified is below.
+When writing your own parser, you should accompany the parser with an "options" class
+which accepts the appropriate keyword arguments. This class' ``__init__`` method should
+store the values that are needed for parsing appropriately. Python Semantic Release will
+pass any configuration options from the configuration file's
+:ref:`commit_parser_options <config-commit_parser_options>`, into your custom parser options
+class. To ensure that the configuration options are passed correctly, the options class
+should inherit from the
+:py:class:`ParserOptions <semantic_release.commit_parser._base.ParserOptions>` class.
 
 The "options" class is used to validate the options which are configured in the repository,
 and to provide default values for these options where appropriate.
 
-If you are writing your own parser, you should accompany it with an "options" class
-which accepts the appropriate keyword arguments. This class' ``__init__`` method should
-store the values that are needed for parsing appropriately.
-
 .. _commit-parsing-commit-parsers:
 
 Commit Parsers

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/docs/configuration.rst

@@ -811,66 +811,14 @@ For more information see :ref:`commit-parsing`.
 
 **Type:** ``dict[str, Any]``
 
-These options are passed directly to the ``parser_options`` method of
-:ref:`the commit parser <config-commit_parser>`, without validation
-or transformation.
+This set of options are passed directly to the commit parser class specified in
+:ref:`the commit parser <config-commit_parser>` configuration option.
 
-For more information, see :ref:`commit-parsing-parser-options`.
-
-The default value for this setting depends on what you specify as
-:ref:`commit_parser <config-commit_parser>`. The table below outlines
-the expections from ``commit_parser`` value to default options value.
-
-==================  ==   =================================
-``commit_parser``        Default ``commit_parser_options``
-==================  ==   =================================
-``"angular"``       ->   .. code-block:: toml
-
-                             [semantic_release.commit_parser_options]
-                             allowed_types = [
-                                 "build", "chore", "ci", "docs", "feat", "fix",
-                                 "perf", "style", "refactor", "test"
-                             ]
-                             minor_types = ["feat"]
-                             patch_types = ["fix", "perf"]
-
-``"emoji"``         ->   .. code-block:: toml
-
-                             [semantic_release.commit_parser_options]
-                             major_tags = [":boom:"]
-                             minor_tags = [
-                                 ":sparkles:", ":children_crossing:", ":lipstick:",
-                                 ":iphone:", ":egg:", ":chart_with_upwards_trend:"
-                             ]
-                             patch_tags = [
-                                 ":ambulance:", ":lock:", ":bug:", ":zap:", ":goal_net:",
-                                 ":alien:", ":wheelchair:", ":speech_balloon:", ":mag:",
-                                 ":apple:", ":penguin:", ":checkered_flag:", ":robot:",
-                                 ":green_apple:"
-                             ]
-
-``"scipy"``         ->   .. code-block:: toml
-
-                             [semantic_release.commit_parser_options]
-                             allowed_tags = [
-                                "API", "DEP", "ENH", "REV", "BUG", "MAINT", "BENCH",
-                                "BLD", "DEV", "DOC", "STY", "TST", "REL", "FEAT", "TEST",
-                             ]
-                             major_tags = ["API",]
-                             minor_tags = ["DEP", "DEV", "ENH", "REV", "FEAT"]
-                             patch_tags = ["BLD", "BUG", "MAINT"]
-
-``"tag"``           ->   .. code-block:: toml
-
-                             [semantic_release.commit_parser_options]
-                             minor_tag = ":sparkles:"
-                             patch_tag = ":nut_and_bolt:"
-
-``"module:class"``  ->   ``**module:class.parser_options()``
-==================  ==   =================================
+For more information (to include defaults), see
+:ref:`commit_parser-builtin-customization`.
 
 **Default:** ``ParserOptions { ... }``, where ``...`` depends on
-:ref:`config-commit_parser` as indicated above.
+:ref:`commit_parser <config-commit_parser>`.
 
 ----
 

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/docs/index.rst

@@ -69,6 +69,7 @@ Documentation Contents
    Migrating from Python Semantic Release v7 <migrating_from_v7>
    Internal API <api/modules>
    Algorithm <algorithm>
+   Changelog <psr_changelog>
    View on GitHub <https://github.com/python-semantic-release/python-semantic-release>
 
 Getting Started

python_semantic_release-9.18.0/docs/psr_changelog.rst

@@ -0,0 +1 @@
+.. include:: ../CHANGELOG.rst

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/pyproject.toml

@@ -6,7 +6,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "python-semantic-release"
-version = "9.16.1"
+version = "9.18.0"
 description = "Automatic Semantic Versioning for Python projects"
 requires-python = ">=3.8"
 license = { text = "MIT" }
@@ -399,6 +399,7 @@ ignore_names = ["change_to_ex_proj_dir", "init_example_project"]
 [tool.semantic_release]
 logging_use_named_masks = true
 commit_parser = "angular"
+commit_parser_options = { parse_squash_commits = true, ignore_merge_commits = true }
 build_command = """
     python -m pip install -e .[build]
     python -m build .
@@ -408,6 +409,7 @@ version_variables = ["src/semantic_release/__init__.py:__version__"]
 version_toml = ["pyproject.toml:project.version"]
 
 [tool.semantic_release.changelog]
+# default_templates = { changelog_file = "CHANGELOG.rst" }
 exclude_commit_patterns = [
   '''chore(?:\([^)]*?\))?: .+''',
   '''ci(?:\([^)]*?\))?: .+''',
@@ -420,6 +422,9 @@ exclude_commit_patterns = [
   # Old semantic-release version commits
   '''^\d+\.\d+\.\d+''',
 ]
+insertion_flag = "=========\nCHANGELOG\n========="
+mode = "update"
+template_dir = "config/release-templates"
 
 [tool.semantic_release.branches.main]
 match = "(main|master)"

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0/src/python_semantic_release.egg-info}/PKG-INFO

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

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/src/python_semantic_release.egg-info/SOURCES.txt

@@ -16,6 +16,7 @@ docs/index.rst
 docs/make.bat
 docs/migrating_from_v7.rst
 docs/multibranch_releases.rst
+docs/psr_changelog.rst
 docs/strict_mode.rst
 docs/troubleshooting.rst
 docs/automatic-releases/cronjobs.rst
@@ -107,6 +108,8 @@ tests/e2e/test_main.py
 tests/e2e/cmd_changelog/__init__.py
 tests/e2e/cmd_changelog/test_changelog.py
 tests/e2e/cmd_changelog/test_changelog_custom_parser.py
+tests/e2e/cmd_changelog/test_changelog_parsing.py
+tests/e2e/cmd_changelog/test_changelog_release_notes.py
 tests/e2e/cmd_config/__init__.py
 tests/e2e/cmd_config/test_generate_config.py
 tests/e2e/cmd_publish/__init__.py

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/src/semantic_release/__init__.py

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

{python_semantic_release-9.16.1 → python_semantic_release-9.18.0}/src/semantic_release/changelog/context.py

@@ -4,10 +4,15 @@ import logging
 import os
 from dataclasses import dataclass
 from enum import Enum
-from pathlib import Path
+from pathlib import Path, PurePosixPath
 from re import compile as regexp
 from typing import TYPE_CHECKING, Any, Callable, Literal
 
+from urllib3.util import Url
+
+from semantic_release.const import PYPI_WEB_DOMAIN
+from semantic_release.helpers import sort_numerically
+
 if TYPE_CHECKING:  # pragma: no cover
     from jinja2 import Environment
 
@@ -24,6 +29,7 @@ class ReleaseNotesContext:
     version: Version
     release: Release
     mask_initial_release: bool
+    license_name: str
     filters: tuple[Callable[..., Any], ...] = ()
 
     def bind_to_environment(self, env: Environment) -> Environment:
@@ -84,13 +90,26 @@ def make_changelog_context(
         hvcs_type=hvcs_client.__class__.__name__.lower(),
         filters=(
             *hvcs_client.get_changelog_context_filters(),
+            create_pypi_url,
             read_file,
             convert_md_to_rst,
             autofit_text_width,
+            sort_numerically,
         ),
     )
 
 
+def create_pypi_url(package_name: str, version: str = "") -> str:
+    project_name = package_name.strip("/").strip()
+    if not project_name:
+        raise ValueError("package_name must not be empty!")
+    return Url(
+        scheme="https",
+        host=PYPI_WEB_DOMAIN,
+        path=str(PurePosixPath("project", project_name, version.strip("/").strip())),
+    ).url.rstrip("/")
+
+
 def read_file(filepath: str) -> str:
     try:
         if not filepath: