Upgrading to v10¶

The upgrade to v10 is primarily motivated by a command injection security vulnerability found in the GitHub Actions configuration interpreter (see details below). We also bundled a number of other changes, including new default configuration values and most importantly, a return to 1-line commit subjects in the default changelog format.

For more specific change details for v10, please refer to the v10.0.0 (2025-05-25) section of the CHANGELOG.

Security Fix: Command Injection Vulnerability (GitHub Actions)¶

In the previous versions of the GitHub Actions configuration, we used a single root_options parameter to pass any options you wanted to pass to the semantic-release main command. This parameter was interpreted as a string and passed directly to the command line, which made it vulnerable to command injection attacks. An attacker could exploit this by crafting a malicious string as the root_options input, and then it would be executed as part of the command line, potentially allowing them to run arbitrary commands within the GitHub Actions Docker container. The ability to exploit this vulnerability is limited to people whom can modify the GitHub Actions workflow file, which is typically only the repository maintainers unless you are pointing at an organizational workflow file or another third-party workflow file.

To mitigate this vulnerability, we have removed the root_options parameter completely and replaced it with individual boolean flag inputs which are then used to select the proper cli parameters for the semantic-release command. Additionally, users can protect themselves by limiting the access to secrets in their GitHub Actions workflows and the permissions of the GitHub Actions CI TOKEN.

This vulnerability existed in both the python-semantic-release/python-semantic-release and python-semantic-release/publish-action actions.

For the main python-semantic-release/python-semantic-release action, the following inputs are now available (in place of the old root_options parameter): config_file, no_operation_mode, strict, and verbosity.

Example migration

If you previously had the following in your GitHub Actions workflow file:

- uses: python-semantic-release/python-semantic-release@v9
  with:
    root_options: "-vv --strict"

It would be updated to:

- uses: python-semantic-release/python-semantic-release@v10
  with:
    strict: true
    verbosity: 2

For the python-semantic-release/publish-action action, the following inputs are now available (in place of the old root_options parameter): config_file, no_operation_mode, and verbosity.

Example migration

If you previously had the following in your GitHub Actions workflow file:

- uses: python-semantic-release/publish-action@v9
  with:
    root_options: "-v -c /path/to/releaserc.yaml"

It would be updated to:

- uses: python-semantic-release/publish-action@v10
  with:
    config_file: /path/to/releaserc.yaml
    verbosity: 1

Changelog Format: 1-Line Commit Subjects¶

In v10, the default changelog format has been changed to use 1-line commit subjects instead of including the full commit message. This change was made to improve the readability of the changelog as many commit messages are long and contain unnecessary details for the changelog.

Important

If you use a squash commit merge strategy, it is recommended that you use the default parse_squash_commits commit parser option to ensure that all the squashed commits are parsed for version bumping and changelog generation. This is the default behavior in v10 across all supported commit parsers. If you are upgrading, you likely will need to manually set this option in your configuration file to ensure that the changelog is generated correctly.

If you do not enable parse_squash_commits, then version will only be determined by the commit subject line and the changelog will only include the commit subject line as well.

Changelog Format: Mask Initial Release¶

In v10, the default behavior for the changelog generation has been changed to mask the initial release in the changelog. This means that the first release will not contain a break down of the different types of changes (e.g., features, fixes, etc.), but instead it will just simply state that this is the initial release.

Changelog Format: Commit Parsing¶

We have made some minor changes to the commit parsing logic in v10 to separate out components of the commit message more clearly. You will find that the ParsedCommit object’s descriptions list will no longer contain any Breaking Change footers, Release Notice footers, PR/MR references, or Issue Closure footers. These were all previously extracted and placed into their own attributes but were still included in the descriptions list. In v10, the descriptions list will only contain the actual commit subject line and any additional commit body text that is not part of the pre-defined footers.

If you were relying on the descriptions list to contain these footers, you will need to update your code and changelog templates to reference the specific attributes you want to use.

Default Configuration Changes¶

The following table summarizes the changes to the default configuration values in v10:

#	Configuration Option	Previous Default Value	New Default Value
1	allow_zero_version	`true`	`false`
2	changelog.mode	`init`	`update`
3	changelog.default_templates.mask_initial_release	`false`	`true`
4	commit_parser_options.parse_squash_commits	`false`	`true`
5	commit_parser_options.ignore_merge_commits	`false`	`true`

Deprecations & Removals¶

No additional deprecations were made in v10, but the following are staged for removal in v11:

Deprecated Features & Functions¶
#	Component	Deprecated	Planned Removal	Notes
1	GitHub Actions root_options	v10.0.0	v10.0.0	Replaced with individual boolean flag inputs. See above for details.
2	Angular Commit Parser	v9.19.0	v11.0.0	Replaced by the Conventional Commit Parser.
3	Tag Commit Parser	v9.12.0	v11.0.0	Replaced by the Emoji Commit Parser.

Note

For the most up-to-date information on the next version deprecations and removals, please refer to the issue #1066.