Provided by: python3-semantic-release_9.21.0-1_all 
NAME
python-semantic-release - python-semantic-release Documentation
Automatic Semantic Versioning for Python projects. This is a Python implementation of semantic-release
for JS by Stephan Bönnemann. If you find this topic interesting you should check out his talk from JSConf
Budapest.
The general idea is to be able to detect what the next version of the project should be based on the
commits. This tool will use that to automate the whole release, upload to an artifact repository and post
changelogs to GitHub. You can run the tool on a CI service, or just run it locally.
INSTALLATION
python3 -m pip install python-semantic-release
semantic-release --help
Python Semantic Release is also available from conda-forge or as a GitHub Action. Read more about the
setup and configuration in our getting started guide.
DOCUMENTATION CONTENTS
Commands
All commands accept a -h/--help option, which displays the help text for the command and exits
immediately.
semantic-release does not allow interspersed arguments and options, which means that the options for
semantic-release are not necessarily accepted one of the subcommands. In particular, the --noop and
-v/--verbose flags must be given to the top-level semantic-release command, before the name of the
subcommand.
For example:
Incorrect:
semantic-release version --print --noop -vv
Correct:
semantic-release -vv --noop version --print
With the exception of semantic-release and semantic-release generate-config, all commands require that
you have set up your project's configuration. To help with this step, semantic-release generate-config
can create the default configuration for you, which will allow you to tweak it to your needs rather than
write it from scratch.
semantic-release
Options:
--version
Display the version of Python Semantic Release and exit
--noop
Use this flag to see what semantic-release intends to do without making changes to your project. When
using this option, semantic-release can be run as many times as you wish without any side-effects.
-v/--verbose
Can be supplied more than once. Controls the verbosity of semantic-releases logging output (default level
is WARNING, use -v for INFO and -vv for DEBUG).
-c/--config [FILE]
Specify the configuration file which Python Semantic Release should use. This can be any of the supported
formats valid for -f/--format [FORMAT]
Default: pyproject.toml
SEE ALSO:
• Configuration
--strict
Enable Strict Mode. This will cause a number of conditions to produce a non-zero exit code when passed,
where they would otherwise have produced an exit code of 0. Enabling this allows, for example, certain
conditions to cause failure of a CI pipeline, while omitting this flag would allow the pipeline to
continue to run.
SEE ALSO:
• Strict Mode
semantic-release version
Detect the semantically correct next version that should be applied to your project.
By default:
• Write this new version to the project metadata locations specified in the configuration file
• Build the project using build_command, if specified
• Create a new commit with these locations and any other assets configured to be included in a release
• Tag this commit according the configured format, with a tag that uniquely identifies the version
being released
• Push the new tag and commit to the remote for the repository
• Create a release (if supported) in the remote VCS for this tag
Changelog generation is done identically to the way it is done in semantic-release changelog, but this
command additionally ensures the updated changelog is included in the release commit that is made.
SEE ALSO:
• semantic-release changelog
• Version Change Reports
• tag_format
• assets
• version_toml
• version_variables
Options:
--print
Print the next version that will be applied, respecting the other command line options that are supplied,
and exit. This flag is useful if you just want to see what the next version will be. Note that instead
of printing nothing at all, if no release will be made, the current version is printed.
For example, you can experiment with which versions would be applied using the other command line
options:
semantic-release version --print
semantic-release version --patch --print
semantic-release version --prerelease --print
--print-tag
Same as the --print flag but prints the complete tag name (ex. v1.0.0 or py-v1.0.0) instead of the raw
version number (1.0.0).
--print-last-released
Print the last released version based on the Git tags. This flag is useful if you just want to see the
released version without determining what the next version will be. Note if the version can not be found
nothing will be printed.
--print-last-released-tag
Same as the --print-last-released flag but prints the complete tag name (ex. v1.0.0 or py-v1.0.0) instead
of the raw version number (1.0.0).
--major/--minor/--patch/--prerelease
Force the next version to increment the major, minor or patch digits, or the prerelease revision,
respectively. These flags are optional but mutually exclusive, so only one may be supplied, or none at
all. Using these flags overrides the usual calculation for the next version; this can be useful, say,
when a project wants to release its initial 1.0.0 version.
WARNING:
Using these flags will override the configured value of prerelease (configured in your Release Group),
regardless of your configuration or the current version.
To produce a prerelease with the appropriate digit incremented you should also supply the
--as-prerelease flag. If you do not, using these flags will force a full (non-prerelease) version to
be created.
For example, suppose your project's current version is 0.2.1-rc.1. The following shows how these options
can be combined with --as-prerelease to force different versions:
semantic-release version --prerelease --print
# 0.2.1-rc.2
semantic-release version --patch --print
# 0.2.2
semantic-release version --minor --print
# 0.3.0
semantic-release version --major --print
# 1.0.0
semantic-release version --minor --as-prerelease --print
# 0.3.0-rc.1
semantic-release version --prerelease --as-prerelease --print
# 0.2.1-rc.2
These options are forceful overrides, but there is no action required for subsequent releases performed
using the usual calculation algorithm.
Supplying --prerelease will cause Python Semantic Release to scan your project history for any previous
prereleases with the same major, minor and patch versions as the latest version and the same prerelease
token as the one passed by command-line or configuration. If one is not found, --prerelease will produce
the next version according to the following format:
f"{latest_version.major}.{latest_version.minor}.{latest_version.patch}-{prerelease_token}.1"
However, if Python Semantic Release identifies a previous prerelease version with the same major, minor
and patch digits as the latest version, and the same prerelease token as the one supplied by command-line
or configuration, then Python Semantic Release will increment the revision found on that previous
prerelease version in its new version.
For example, if "0.2.1-rc.1" and already exists as a previous version, and the latest version is "0.2.1",
invoking the following command will produce "0.2.1-rc.2":
semantic-release version --prerelease --prerelease-token "rc" --print
WARNING:
This is true irrespective of the branch from which "0.2.1-rc.1" was released from. The check for
previous prereleases "leading up to" this normal version is intended to help prevent collisions in git
tags to an extent, but isn't foolproof. As the example shows it is possible to release a prerelease
for a normal version that's already been released when using this flag, which would in turn be ignored
by tools selecting versions by SemVer precedence rules.
SEE ALSO:
• Configuration
• branches
--as-prerelease
After performing the normal calculation of the next version, convert the resulting next version to a
prerelease before applying it. As with --major/--minor/--patch/--prerelease, this option is a forceful
override, but no action is required to resume calculating versions as normal on the subsequent releases.
The main distinction between --prerelease and --as-prerelease is that the latter will not force a new
version if one would not have been released without supplying the flag.
This can be useful when making a single prerelease on a branch that would typically release normal
versions.
If not specified in --prerelease-token [VALUE], the prerelease token is identified using the Multibranch
Release Configuration
See the examples alongside --major/--minor/--patch/--prerelease for how to use this flag.
--prerelease-token [VALUE]
Force the next version to use the value as the prerelease token. This overrides the configured value if
one is present. If not used during a release producing a prerelease version, this option has no effect.
--build-metadata [VALUE]
If given, append the value to the newly calculated version. This can be used, for example, to attach a
run number from a CI service or a date to the version and tag that are created.
This value can also be set using the environment variable PSR_BUILD_METADATA
For example, assuming a project is currently at version 1.2.3:
$ semantic-release version --minor --print
1.3.0
$ semantic-release version --minor --print --build-metadata "run.12345"
1.3.0+run.12345
--commit/--no-commit
Whether or not to perform a git commit on modifications to source files made by semantic-release during
this command invocation, and to run git tag on this new commit with a tag corresponding to the new
version.
If --no-commit is supplied, it may disable other options derivatively; please see below.
Default: --commit
SEE ALSO:
• tag_format
--tag/--no-tag
Whether or not to perform a git tag to apply a tag of the corresponding to the new version during this
command invocation. This option manages the tag application separate from the commit handled by the
--commit option.
If --no-tag is supplied, it may disable other options derivatively; please see below.
Default: --tag
--changelog/--no-changelog
Whether or not to update the changelog file with changes introduced as part of the new version released.
Default: --changelog
SEE ALSO:
• changelog
• Version Change Reports
--push/--no-push
Whether or not to push new commits and/or tags to the remote repository.
Default: --no-push if --no-commit and --no-tag is also supplied, otherwise push is the default.
--vcs-release/--no-vcs-release
Whether or not to create a "release" in the remote VCS service, if supported. Currently releases in
GitHub and Gitea remotes are supported. If releases aren't supported in a remote VCS, this option will
not cause a command failure, but will produce a warning.
Default: --no-vcs-release if --no-push is supplied (including where this is implied by supplying only
--no-commit), otherwise --vcs-release
--skip-build
If passed, skip execution of the build_command after version stamping and changelog generation.
semantic-release publish
Publish a distribution to a VCS release. Uploads using publish
SEE ALSO:
• publish
• build_command
Options:
--tag
The tag associated with the release to publish to. If not given or set to "latest", then Python Semantic
Release will examine the Git tags in your repository to identify the latest version, and attempt to
publish to a Release corresponding to this version.
Default: "latest"
semantic-release generate-config
Generate default configuration for semantic-release, to help you get started quickly. You can inspect the
defaults, write to a file and then edit according to your needs. For example, to append the default
configuration to your pyproject.toml file, you can use the following command:
$ semantic-release generate-config -f toml --pyproject >> pyproject.toml
If your project doesn't already leverage TOML files for configuration, it might better suit your project
to use JSON instead:
$ semantic-release generate-config -f json
If you would like to add JSON configuration to a shared file, e.g. package.json, you can then simply add
the output from this command as a top-level key to the file.
Note: Because there is no "null" or "nil" concept in TOML (see the relevant GitHub issue), configuration
settings which are None by default are omitted from the default configuration.
SEE ALSO:
• Configuration
Options:
-f/--format [FORMAT]
The format that the default configuration should be generated in. Valid choices are toml and json
(case-insensitive).
Default: toml
--pyproject
If used alongside --format json, this option has no effect. When using --format=toml, if specified the
configuration will sit under a top-level key of tool.semantic_release to comply with PEP 518; otherwise,
the configuration will sit under a top-level key of semantic_release.
semantic-release changelog
Generate and optionally publish a changelog for your project. The changelog is generated based on a
template which can be customized.
Python Semantic Release uses Jinja as its templating engine; as a result templates need to be written
according to the Template Designer Documentation.
SEE ALSO:
• changelog
• environment
• Version Change Reports
Options:
--post-to-release-tag [TAG]
If supplied, attempt to find a release in the remote VCS corresponding to the Git tag TAG, and post the
generated changelog to that release. If the tag exists but no corresponding release is found in the
remote VCS, then Python Semantic Release will attempt to create one.
If using this option, the relevant authentication token must be supplied via the relevant environment
variable. For more information, see Creating VCS Releases.
Strict Mode
Strict Mode is enabled by use of the strict parameter to the main command for Python Semantic Release.
Strict Mode alters the behavior of Python Semantic Release when certain conditions are encountered that
prevent Python Semantic Release from performing an action. Typically, this will result in a warning
becoming an error, or a different exit code (0 vs non-zero) being produced when Python Semantic Release
exits early.
For example:
#!/usr/bin/bash
set -euo pipefail
git checkout $NOT_A_RELEASE_BRANCH
pip install \
black \
isort \
twine \
pytest \
python-semantic-release
isort . # sort imports
black . # format the code
pytest # test the code
semantic-release --strict version # ERROR - not a release branch
twine upload dist/* # publish the code
Using Strict Mode with the --strict flag ensures this simple pipeline will fail while running
semantic-release, as the non-zero exit code will cause it to stop when combined with the -e option.
Without Strict Mode, the semantic-release command will exit with code 0, causing the above pipeline to
continue.
The specific effects of enabling Strict Mode are detailed below.
Non-Release Branches
When running in Strict Mode, invoking Python Semantic Release on a non-Release branch will cause an error
with a non-zero exit code. This means that you can prevent an automated script from running further
against branches you do not want to release from, for example in multibranch CI pipelines.
Running without Strict Mode will allow subsequent steps in the pipeline to also execute, but be aware
that certain actions that Python Semantic Release may perform for you will likely not have been carried
out, such as writing to files or creating a git commit in your repository.
SEE ALSO:
• Multibranch Releases
Version Already Released/No Release To Be Made
When Strict Mode is not enabled and Python Semantic Release identifies that no release needs to be made,
it will exit with code 0. You can cause Python Semantic Release to raise an error if no release needs to
be made by enabling Strict Mode.
Configuration
Configuration is read from a file which can be specified using the \\-\\-config option to
semantic-release. Python Semantic Release currently supports a configuration in either TOML or JSON
format, and will attempt to auto-detect and parse either format.
When using a JSON-format configuration file, Python Semantic Release looks for its settings beneath a
top-level semantic_release key; when using a TOML-format configuration file, Python Semantic Release
first checks for its configuration under the table [tool.semantic_release] (in line with the convention
for Python tools to require their configuration under the top-level tool table in their pyproject.toml
file), followed by [semantic_release], which may be more desirable if using a file other than the default
pyproject.toml for configuration.
The examples on this page are given in TOML format, however there is no limitation on using JSON instead.
In fact, if you would like to convert any example below to its JSON equivalent, the following commands
will do this for you (in Bash):
export TEXT="<the TOML to convert>"
cat <<EOF | python3
import tomlkit, json
print(json.dumps(tomlkit.loads('''$TEXT'''), indent=4))
EOF
A note on null
In TOML, there is no such thing as a "null" or "nil" value, and this isn't planned as a language feature
according to the relevant GitHub issue. In Python Semantic Release, options which default to None are
inferred from the relevant configuration settings not being present at all in your configuration.
Because of this limitation, it's currently not possible to explicitly specify those settings as "null" in
TOML-format configuration. Technically it is possible in JSON-format configuration, but it's recommended
to keep consistency and just omit the relevant settings.
Environment Variables
Some settings are best pulled from environment variables rather than being stored in plaintext in your
configuration file. Python Semantic Release can be configured to look for an environment variable value
to use for a given setting, but this feature is not available for all settings. In order to use an
environment variable for a setting, you must indicate in your configuration file the name of the
environment variable to use.
The traditional and most common use case for environment variable use is for passing authentication
tokens to Python Semantic Release. You do NOT want to hard code your authentication token in your
configuration file, as this is a security risk. A plaintext token in your configuration file could be
exposed to anyone with access to your repository, including long after its deleted if a token is in your
git history. Instead, define the name of the environment variable which contains your remote.token, such
as GH_TOKEN, in your configuration file, and Python Semantic Release will do the rest, as seen below.
[semantic_release.remote.token]
env = "GH_TOKEN"
Given basic TOML syntax compatibility, this is equivalent to:
[semantic_release.remote]
token = { env = "GH_TOKEN" }
The general format for specifying that some configuration should be sourced from an environment variable
is:
[semantic_release.variable]
env = "ENV_VAR"
default_env = "FALLBACK_ENV_VAR"
default = "default value"
In this structure:
• env represents the environment variable that Python Semantic Release will search for
• default_env is a fallback environment variable to read in case the variable specified by env is not
set. This is optional - if not specified then no fallback will be used.
• default is a default value to use in case the environment variable specified by env is not set. This
is optional - if default is not specified then the environment variable specified by env is
considered required.
semantic_release settings
The following sections outline all the definitions and descriptions of each supported configuration
setting. If there are type mis-matches, PSR will throw validation errors upon load. If a setting is not
provided, than PSR will fill in the value with the default value.
Python Semantic Release expects a root level key to start the configuration definition. Make sure to use
the correct root key depending on the configuration format you are using.
NOTE:
If you are using pyproject.toml, this heading should include the tool prefix as specified within PEP
517, resulting in [tool.semantic_release].
NOTE:
If you are using a releaserc.toml, use [semantic_release] as the root key
NOTE:
If you are using a releaserc.json, semantic_release must be the root key in the top level dictionary.
----
allow_zero_version
Introduced in v9.2.0
Type: bool
This flag controls whether or not Python Semantic Release will use version numbers aligning with the
0.x.x pattern.
If set to true and starting at 0.0.0, a minor bump would set the next version as 0.1.0 whereas a patch
bump would set the next version as 0.0.1. A breaking change (ie. major bump) would set the next version
as 1.0.0 unless the major_on_zero is set to false.
If set to false, Python Semantic Release will consider the first possible version to be 1.0.0, regardless
of patch, minor, or major change level. Additionally, when allow_zero_version is set to false, the
major_on_zero setting is ignored.
Default: true
----
assets
Type: list[str]
One or more paths to additional assets that should committed to the remote repository in addition to any
files modified by writing the new version.
Default: []
----
branches
This setting is discussed in more detail at Multibranch Releases
Default:
[semantic_release.branches.main]
match = "(main|master)"
prerelease_token = "rc"
prerelease = false
----
build_command
Type: Optional[str]
Command to use to build the current project during semantic-release version.
Python Semantic Release will execute the build command in the OS default shell with a subset of
environment variables. PSR provides the variable NEW_VERSION in the environment with the value of the
next determined version. The following table summarizes all the environment variables that are passed on
to the build_command runtime if they exist in the parent process.
If you would like to pass additional environment variables to your build command, see build_command_env.
┌──────────────────────────┬───────────────────────────────────────┐
│ Variable Name │ Description │
├──────────────────────────┼───────────────────────────────────────┤
│ CI │ Pass-through true if exists in │
│ │ process env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ BITBUCKET_CI │ true if Bitbucket CI variables exist │
│ │ in env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ GITHUB_ACTIONS │ Pass-through true if exists in │
│ │ process env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ GITEA_ACTIONS │ Pass-through true if exists in │
│ │ process env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ GITLAB_CI │ Pass-through true if exists in │
│ │ process env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ HOME │ Pass-through HOME of parent process │
├──────────────────────────┼───────────────────────────────────────┤
│ NEW_VERSION │ Semantically determined next version │
│ │ (ex. 1.2.3) │
├──────────────────────────┼───────────────────────────────────────┤
│ PATH │ Pass-through PATH of parent process │
├──────────────────────────┼───────────────────────────────────────┤
│ PSR_DOCKER_GITHUB_ACTION │ Pass-through true if exists in │
│ │ process env, unset otherwise │
├──────────────────────────┼───────────────────────────────────────┤
│ VIRTUAL_ENV │ Pass-through VIRTUAL_ENV if exists in │
│ │ process env, unset otherwise │
└──────────────────────────┴───────────────────────────────────────┘
In addition, on windows systems these environment variables are passed:
┌─────────────────────────┬───────────────────────────────────────┐
│ Variable Name │ Description │
├─────────────────────────┼───────────────────────────────────────┤
│ ALLUSERSAPPDATA │ Pass-through ALLUSERAPPDATA if exists │
│ │ in process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ ALLUSERSPROFILE │ Pass-through ALLUSERSPPPROFILE if │
│ │ exists in process env, unset │
│ │ otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ APPDATA │ Pass-through APPDATA if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ COMMONPROGRAMFILES │ Pass-through COMMONPROGRAMFILES if │
│ │ exists in process env, unset │
│ │ otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ COMMONPROGRAMFILES(X86) │ Pass-through COMMONPROGRAMFILES(X86) │
│ │ if exists in process env, unset │
│ │ otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ DEFAULTUSERPROFILE │ Pass-through DEFAULTUSERPROFILE if │
│ │ exists in process env, unset │
│ │ otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ HOMEPATH │ Pass-through HOMEPATH if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ PATHEXT │ Pass-through PATHEXT if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ PROFILESFOLDER │ Pass-through PROFILESFOLDER if exists │
│ │ in process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ PROGRAMFILES │ Pass-through PROGRAMFILES if exists │
│ │ in process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ PROGRAMFILES(X86) │ Pass-through PROGRAMFILES(X86) if │
│ │ exists in process env, unset │
│ │ otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ SYSTEM │ Pass-through SYSTEM if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ SYSTEM16 │ Pass-through SYSTEM16 if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ SYSTEM32 │ Pass-through SYSTEM32 if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ SYSTEMDRIVE │ Pass-through SYSTEMDRIVE if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ SYSTEMROOT │ Pass-through SYSTEMROOT if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ TEMP │ Pass-through TEMP if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ TMP │ Pass-through TMP if exists in process │
│ │ env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ USERPROFILE │ Pass-through USERPROFILE if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ USERSID │ Pass-through USERSID if exists in │
│ │ process env, unset otherwise │
├─────────────────────────┼───────────────────────────────────────┤
│ WINDIR │ Pass-through WINDIR if exists in │
│ │ process env, unset otherwise │
└─────────────────────────┴───────────────────────────────────────┘
Default: None (not specified)
----
build_command_env
Introduced in v9.7.2
Type: Optional[list[str]]
List of environment variables to include or pass-through on to the build command that executes during
semantic-release version.
This configuration option allows the user to extend the list of environment variables from the table
above in build_command. The input is a list of strings where each individual string handles a single
variable definition. There are two formats accepted and are detailed in the following table:
┌────────────────┬───────────────────────────────────────┐
│ FORMAT │ Description │
├────────────────┼───────────────────────────────────────┤
│ VAR_NAME │ Detects value from the PSR process │
│ │ environment, and passes value to │
│ │ build_command process │
├────────────────┼───────────────────────────────────────┤
│ VAR_NAME=value │ Sets variable name to value inside of │
│ │ build_command process │
└────────────────┴───────────────────────────────────────┘
NOTE:
Although variable name capitalization is not required, it is recommended as to be in-line with the
POSIX-compliant recommendation for shell variable names.
Default: None (not specified)
----
changelog
This section outlines the configuration options available that modify changelog generation.
NOTE:
pyproject.toml: [tool.semantic_release.changelog]
releaserc.toml: [semantic_release.changelog]
releaserc.json: { "semantic_release": { "changelog": {} } }
----
changelog_file
WARNING:
Deprecated in v9.11.0. This setting has been moved to changelog.default_templates.changelog_file for a
more logical grouping. This setting will be removed in a future major release.
Type: str
Specify the name of the changelog file that will be created. This file will be created or overwritten (if
it previously exists) with the rendered default template included with Python Semantic Release.
Depending on the file extension of this setting, the changelog will be rendered in the format designated
by the extension. PSR, as of v9.11.0, provides a default changelog template in both Markdown (.md) and
reStructuredText (.rst) formats. If the file extension is not recognized, the changelog will be rendered
in Markdown format, unless the output_format setting is set.
If you are using the template_dir setting for providing customized templates, this setting is not used.
See template_dir for more information.
Default: "CHANGELOG.md"
----
default_templates
NOTE:
This section of the configuration contains options which customize or modify the default changelog
templates included with PSR.
pyproject.toml: [tool.semantic_release.changelog.default_templates]
releaserc.toml: [semantic_release.changelog.default_templates]
releaserc.json: { "semantic_release": { "changelog": { "default_templates": {} } } }
----
changelog_file
Introduced in v9.11.0.
Type: str
Specify the name of the changelog file that will be created. This file will be created or overwritten (if
it previously exists) with the rendered default template included with Python Semantic Release.
Depending on the file extension of this setting, the changelog will be rendered in the format designated
by the extension. PSR, as of v9.11.0, provides a default changelog template in both Markdown (.md) and
reStructuredText (.rst) formats. If the file extension is not recognized, the changelog will be rendered
in Markdown format, unless the output_format setting is set.
If you are using the template_dir setting for providing customized templates, this setting is not used.
See template_dir for more information.
Default: "CHANGELOG.md"
----
mask_initial_release
Introduced in v9.14.0
Type: bool
This option toggles the behavior of the changelog and release note templates to mask the release details
specifically for the first release. When set to true, the first version release notes will be masked with
a generic message as opposed to the usual commit details. When set to false, the release notes will be
generated as normal.
The reason for this setting is to improve clarity to your audience. It conceptually does NOT make sense
to have a list of changes (i.e. a Changelog) for the first release since nothing has been published yet,
therefore in the eyes of your consumers what change is there to document?
The message details can be found in the first_release.md.j2 and first_release.rst.j2 templates of the
default changelog template directory.
Default: false
SEE ALSO:
• Using the Default Changelog
----
output_format
Introduced in v9.10.0
Type: Literal["md", "rst"]
This setting is used to specify the output format the default changelog template will use when rendering
the changelog. PSR supports both Markdown (md) and reStructuredText (rst) formats.
This setting will take precedence over the file extension of the changelog_file setting. If this setting
is omitted, the file extension of the changelog_file setting will be used to determine the output format.
If the file extension is not recognized, the output format will default to Markdown.
Default: "md"
SEE ALSO:
• changelog_file
----
environment
NOTE:
This section of the configuration contains options which customize the template environment used to
render templates such as the changelog. Most options are passed directly to the jinja2.Environment
constructor, and further documentation one these parameters can be found there.
pyproject.toml: [tool.semantic_release.changelog.environment]
releaserc.toml: [semantic_release.changelog.environment]
releaserc.json: { "semantic_release": { "changelog": { "environment": {} } } }
----
autoescape
Type: Union[str, bool]
If this setting is a string, it should be given in module:attr form; Python Semantic Release will attempt
to dynamically import this string, which should represent a path to a suitable callable that satisfies
the following:
As of Jinja 2.4 this can also be a callable that is passed the template name and has to return true or
false depending on autoescape should be enabled by default.
The result of this dynamic import is passed directly to the jinja2.Environment constructor.
If this setting is a boolean, it is passed directly to the jinja2.Environment constructor.
Default: false
----
block_start_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "{%"
----
block_end_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "%}"
----
comment_start_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: {#
----
comment_end_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "#}"
----
extensions
Type: list[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: []
----
keep_trailing_newline
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
line_comment_prefix
Type: Optional[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: None (not specified)
----
line_statement_prefix
Type: Optional[str]
This setting is passed directly to the jinja2.Environment constructor.
Default: None (not specified)
----
lstrip_blocks
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
newline_sequence
Type: Literal["\n", "\r", "\r\n"]
This setting is passed directly to the jinja2.Environment constructor.
Default: "\n"
----
trim_blocks
Type: bool
This setting is passed directly to the jinja2.Environment constructor.
Default: false
----
variable_start_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "{{"
----
variable_end_string
Type: str
This setting is passed directly to the jinja2.Environment constructor.
Default: "}}"
----
exclude_commit_patterns
Type: list[str]
Any patterns specified here will be excluded from the commits which are available to your changelog. This
allows, for example, automated commits to be removed if desired. Python Semantic Release also removes
its own commits from the Changelog via this mechanism; therefore if you change the automated commit
message that Python Semantic Release uses when making commits, you may wish to add the old commit message
pattern here.
The patterns in this list are treated as regular expressions.
Default: []
----
mode
Introduced in v9.10.0
Type: Literal["init", "update"]
This setting is a flag that is ultimately passed into the changelog context environment. It sets the
value of context.changelog_mode to a string value of either init or update.
When used with the provided changelog template, it will determine the behavior of how the changelog is
written. When the mode is set to init, the changelog file will be written from scratch, overwriting any
existing changelog file. This is the v8 and v9 default behavior.
When the mode is set to update, the changelog file will look for the insertion_flag value in the
changelog file (defined by changelog_file) and insert the new version information at that location.
If you are using a custom template directory, the context.changelog_mode value will exist in the
changelog context but it is up to your implementation to determine if and/or how to use it.
Default: init
SEE ALSO:
• Using the Default Changelog
----
insertion_flag
Introduced in v9.10.0
Type: str
A string that will be used to identify where the new version should be inserted into the changelog file
(as defined by changelog_file) when the changelog mode is set to update.
If you modify this value in your config, you will need to manually update any saved changelog file to
match the new insertion flag if you use the update mode. In init mode, the changelog file will be
overwritten as normal.
In v9.11.0, the insertion_flag default value became more dynamic with the introduction of an
reStructuredText template. The default value will be set depending on the output_format setting. The
default flag values are:
┌──────────────────┬────────────────────────┐
│ Output Format │ Default Insertion Flag │
├──────────────────┼────────────────────────┤
│ Markdown (md) │ <!-- version list --> │
├──────────────────┼────────────────────────┤
│ reStructuredText │ ..\n version list │
└──────────────────┴────────────────────────┘
Default: various, see above
----
template_dir
Type: str
When files exist within the specified directory, they will be used as templates for the changelog
rendering process. Regardless if the directory includes a changelog file, the provided directory will be
rendered and files placed relative to the root of the project directory.
No default changelog template or release notes template will be used when this directory exists and the
directory is not empty. If the directory is empty, the default changelog template will be used.
This option is discussed in more detail at Version Change Reports
Default: "templates"
----
commit_author
Type: str
Author used in commits in the format name <email>.
NOTE:
If you are using the built-in GitHub Action, the default value is set to github-actions
<actions@github.com>. You can modify this with the git_committer_name and git_committer_email inputs.
SEE ALSO:
• GitHub Actions
Default: semantic-release <semantic-release>
----
commit_message
Type: str
Commit message to use when making release commits. The message can use {version} as a format key, in
which case the version being released will be formatted into the message.
If at some point in your project's lifetime you change this, you may wish to consider, adding the old
message pattern(s) to exclude_commit_patterns.
Default: "{version}\n\nAutomatically generated by python-semantic-release"
----
commit_parser
Type: str
Specify which commit parser Python Semantic Release should use to parse the commits within the Git
repository.
Built-in parsers:
• angular - AngularCommitParser (deprecated in v9.19.0)
• conventional - ConventionalCommitParser (available in v9.19.0+)
• emoji - EmojiCommitParser
• scipy - ScipyCommitParser
• tag - TagCommitParser (deprecated in v9.12.0)
You can set any of the built-in parsers by their keyword but you can also specify your own commit parser
in path/to/module_file.py:Class or module:Class form.
For more information see Commit Parsing.
Default: "conventional"
----
commit_parser_options
Type: dict[str, Any]
This set of options are passed directly to the commit parser class specified in the commit parser
configuration option.
For more information (to include defaults), see Customization.
Default: ParserOptions { ... }, where ... depends on commit_parser.
----
logging_use_named_masks
Type: bool
Whether or not to replace secrets identified in logging messages with named masks identifying which
secrets were replaced, or use a generic string to mask them.
Default: false
----
major_on_zero
Type: bool
This flag controls whether or not Python Semantic Release will increment the major version upon a
breaking change when the version matches 0.y.z. This value is set to true by default, where breaking
changes will increment the 0 major version to 1.0.0 like normally expected.
If set to false, major (breaking) releases will increment the minor digit of the version while the major
version is 0, instead of the major digit. This allows for continued breaking changes to be made while the
major version remains 0.
From the Semantic Versioning Specification:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API
SHOULD NOT be considered stable.
When you are ready to release a stable version, set major_on_zero to true and run Python Semantic Release
again. This will increment the major version to 1.0.0.
When allow_zero_version is set to false, this setting is ignored.
Default: true
----
no_git_verify
Introduced in v9.8.0
Type: bool
This flag is passed along to git upon performing a git commit during semantic-release version.
When true, it will bypass any git hooks that are set for the repository when Python Semantic Release
makes a version commit. When false, the commit is performed as normal. This option has no effect when
there are not any git hooks configured nor when the --no-commit option is passed.
Default: false
----
publish
This section defines configuration options that modify semantic-release publish.
NOTE:
pyproject.toml: [tool.semantic_release.publish]
releaserc.toml: [semantic_release.publish]
releaserc.json: { "semantic_release": { "publish": {} } }
----
dist_glob_patterns
Type: list[str]
Upload any files matching any of these globs to your VCS release. Each item in this list should be a
string containing a Unix-style glob pattern.
Default: ["dist/*"]
----
upload_to_vcs_release
Type: bool
If set to true, upload any artifacts matched by the dist_glob_patterns to the release created in the
remote VCS corresponding to the latest tag. Artifacts are only uploaded if release artifact uploads are
supported by the VCS type.
Default: true
----
remote
The remote configuration is a group of settings that configure PSR's integration with remote version
control systems.
NOTE:
pyproject.toml: [tool.semantic_release.remote]
releaserc.toml: [semantic_release.remote]
releaserc.json: { "semantic_release": { "remote": {} } }
----
api_domain
Type: Optional[str | Dict['env', str]]
The hosting domain for the API of your remote HVCS if different than the domain. Generally, this will be
used to specify a separate subdomain that is used for API calls rather than the primary domain (ex.
api.github.com).
Most on-premise HVCS installations will NOT use this setting! Whether or not this value is used depends
on the HVCS configured (and your server administration) in the remote.type setting and used in tandem
with the remote.domain setting.
When using a custom remote.domain and a HVCS remote.type that is configured with a separate domain or
sub-domain for API requests, this value is used to configure the location of API requests that are sent
from PSR.
Most on-premise or self-hosted HVCS environments will use a path prefix to handle inbound API requests,
which means this value will ignored.
PSR knows the expected api domains for known cloud services and their associated api domains which means
this value is not necessary to explicitly define for services as bitbucket.org, and github.com.
Including the protocol schemes, such as https://, for the API domain is optional. Secure HTTPS
connections are assumed unless the setting of remote.insecure is true.
Default: None
----
domain
Type: Optional[str | Dict['env', str]]
The host domain for your HVCS server. This setting is used to support on-premise installations of HVCS
providers with custom domain hosts.
If you are using the official domain of the associated remote.type, this value is not required. PSR will
use the default domain value for the remote.type when not specified. For example, when
remote.type="github" is specified the default domain of github.com is used.
Including the protocol schemes, such as https://, for the domain value is optional. Secure HTTPS
connections are assumed unless the setting of remote.insecure is true.
This setting also supports reading from an environment variable for ease-of-use in CI pipelines. See
Environment Variable for more information. Depending on the remote.type, the default environment variable
for the default domain's CI pipeline environment will automatically be checked so this value is not
required in default environments. For example, when remote.type="gitlab" is specified, PSR will look to
the CI_SERVER_URL environment variable when remote.domain is not specified.
Default: None
SEE ALSO:
• remote.api_domain
----
ignore_token_for_push
Type: bool
If set to true, ignore the authentication token when pushing changes to the remote. This is ideal, for
example, if you already have SSH keys set up which can be used for pushing.
Default: false
----
insecure
Introduced in v9.4.2
Type: bool
Insecure is used to allow non-secure HTTP connections to your HVCS server. If set to true, any domain
value passed will assume http:// if it is not specified and allow it. When set to false (implicitly or
explicitly), it will force https:// communications.
When a custom domain or api_domain is provided as a configuration, this flag governs the protocol scheme
used for those connections. If the protocol scheme is not provided in the field value, then this insecure
option defines whether HTTP or HTTPS is used for the connection. If the protocol scheme is provided in
the field value, it must match this setting or it will throw an error.
The purpose of this flag is to prevent any typos in provided domain and api_domain values that
accidentally specify an insecure connection but allow users to toggle the protection scheme off when
desired.
Default: false
----
name
Type: str
Name of the remote to push to using git push -u $name <branch_name>
Default: "origin"
----
token
Type: Optional[str | Dict['env', str]]
Environment Variable from which to source the authentication token for the remote VCS. Common examples
include "GH_TOKEN", "GITLAB_TOKEN" or "GITEA_TOKEN", however, you may choose to use a custom environment
variable if you wish.
NOTE:
By default, this is a mandatory environment variable that must be set before using any functionality
that requires authentication with your remote VCS. If you are using this token to enable push access
to the repository, it must also be set before attempting to push.
If your push access is enabled via SSH keys instead, then you do not need to set this environment
variable in order to push the version increment, changelog and modified source code assets to the
remote using semantic-release version. However, you will need to disable release creation using the
--vcs-release/--no-vcs-release option, among other options, in order to use Python Semantic Release
without configuring the environment variable for your remote VCS authentication token.
The default value for this setting depends on what you specify as remote.type. Review the table below to
see what the default token value will be for each remote type.
┌─────────────┬────┬─────────────────────────────┐
│ remote.type │ │ Default remote.token │
├─────────────┼────┼─────────────────────────────┤
│ "github" │ -> │ { env = "GH_TOKEN" } │
├─────────────┼────┼─────────────────────────────┤
│ "gitlab" │ -> │ { env = "GITLAB_TOKEN" } │
├─────────────┼────┼─────────────────────────────┤
│ "gitea" │ -> │ { env = "GITEA_TOKEN" } │
├─────────────┼────┼─────────────────────────────┤
│ "bitbucket" │ -> │ { env = "BITBUCKET_TOKEN" } │
└─────────────┴────┴─────────────────────────────┘
Default: { env = "<envvar name>" }, where <envvar name> depends on remote.type as indicated above.
----
type
Type: Literal["bitbucket", "gitea", "github", "gitlab"]
The type of the remote VCS. Currently, Python Semantic Release supports "github", "gitlab", "gitea" and
"bitbucket". Not all functionality is available with all remote types, but we welcome pull requests to
help improve this!
Default: "github"
----
url
Type: Optional[str | Dict['env', str]]
An override setting used to specify the remote upstream location of git push.
Not commonly used! This is used to override the derived upstream location when the desired push location
is different than the location the repository was cloned from.
This setting will override the upstream location url that would normally be derived from the remote.name
location of your git repository.
Default: None
----
tag_format
Type: str
Specify the format to be used for the Git tag that will be added to the repo during a release invoked via
semantic-release version. The format string is a regular expression, which also must include the format
keys below, otherwise an exception will be thrown. It may include any of the optional format keys, in
which case the contents described will be formatted into the specified location in the Git tag that is
created.
For example, "(dev|stg|prod)-v{version}" is a valid tag_format matching tags such as:
• dev-v1.2.3
• stg-v0.1.0-rc.1
• prod-v2.0.0+20230701
This format will also be used for parsing tags already present in the repository into semantic versions;
therefore if the tag format changes at some point in the repository's history, historic versions that no
longer match this pattern will not be considered as versions.
┌────────────┬───────────┬──────────────────────────────┐
│ Format Key │ Mandatory │ Contents │
├────────────┼───────────┼──────────────────────────────┤
│ {version} │ Yes │ The new semantic version │
│ │ │ number, for example 1.2.3, │
│ │ │ or 2.1.0-alpha.1+build.1234 │
└────────────┴───────────┴──────────────────────────────┘
Tags which do not match this format will not be considered as versions of your project.
Default: "v{version}"
----
version_toml
Type: list[str]
This configuration option is similar to version_variables, but it uses a TOML parser to interpret the
data structure before, inserting the version. This allows users to use dot-notation to specify the
version via the logical structure within the TOML file, which is more accurate than a pattern replace.
The version_toml option is commonly used to update the version number in the project definition file:
pyproject.toml as seen in the example below.
As of v9.20.0, the version_toml option accepts a colon-separated definition with either 2 or 3 parts. The
2-part definition includes the file path and the version parameter (in dot-notation). Newly with v9.20.0,
it also accepts an optional 3rd part to allow configuration of the format type.
Available Format Types
• nf: Number format (ex. 1.2.3)
• tf: Tag Format (ex. v1.2.3)
If the format type is not specified, it will default to the number format.
Example
[semantic_release]
version_toml = [
# "file:variable:[format_type]"
"pyproject.toml:tool.poetry.version", # Implied Default: Number format
"definition.toml:project.version:nf", # Number format
"definition.toml:project.release:tf", # Tag format
]
This configuration will result in the following changes:
diff a/pyproject.toml b/pyproject.toml
[tool.poetry]
- version = "0.1.0"
+ version = "0.2.0"
diff a/definition.toml b/definition.toml
[project]
name = "example"
- version = "0.1.0"
+ version = "0.1.0"
- release = "v0.1.0"
+ release = "v0.2.0"
Default: []
----
version_variables
Type: list[str]
The version_variables configuration option is a list of string definitions that defines where the version
number should be updated in the repository, when a new version is released.
As of v9.20.0, the version_variables option accepts a colon-separated definition with either 2 or 3
parts. The 2-part definition includes the file path and the variable name. Newly with v9.20.0, it also
accepts an optional 3rd part to allow configuration of the format type.
Available Format Types
• nf: Number format (ex. 1.2.3)
• tf: Tag Format (ex. v1.2.3)
If the format type is not specified, it will default to the number format.
Prior to v9.20.0, PSR only supports entries with the first 2-parts as the tag format type was not
available and would only replace numeric version numbers.
Example
[semantic_release]
tag_format = "v{version}"
version_variables = [
# "file:variable:format_type"
"src/semantic_release/__init__.py:__version__", # Implied Default: Number format
"docs/conf.py:version:nf", # Number format for sphinx docs
"kustomization.yml:newTag:tf", # Tag format
]
First, the __version__ variable in src/semantic_release/__init__.py will be updated with the next version
using the SemVer number format.
diff a/src/semantic_release/__init__.py b/src/semantic_release/__init__.py
- __version__ = "0.1.0"
+ __version__ = "0.2.0"
Then, the version variable in docs/conf.py will be updated with the next version with the next version
using the SemVer number format because of the explicit nf.
diff a/docs/conf.py b/docs/conf.py
- version = "0.1.0"
+ version = "0.2.0"
Lastly, the newTag variable in kustomization.yml will be updated with the next version with the next
version using the configured tag_format because the definition included tf.
diff a/kustomization.yml b/kustomization.yml
images:
- name: repo/image
- newTag: v0.1.0
+ newTag: v0.2.0
How It works
Each version variable will be transformed into a Regular Expression that will be used to substitute the
version number in the file. The replacement algorithm is ONLY a pattern match and replace. It will NOT
evaluate the code nor will PSR understand any internal object structures (ie. file:object.version will
not work).
The regular expression generated from the version_variables definition will:
1. Look for the specified variable name in the file. The variable name can be enclosed by single (') or
double (") quotation marks but they must match.
2. The variable name defined by variable and the version must be separated by an operand symbol (=, :,
:=, or @). Whitespace is optional around the symbol.
3. The value of the variable must match a SemVer regular expression and can be enclosed by single (') or
double (") quotation marks but they must match. However, the enclosing quotes of the value do not have
to match the quotes surrounding the variable name.
4. If the format type is set to tf then the variable value must have the matching prefix and suffix of
the tag_format setting around the SemVer version number.
Given the pattern matching nature of this feature, the Regular Expression is able to support most file
formats because of the similarity of variable declaration across programming languages. PSR specifically
supports Python, YAML, and JSON as these have been the most commonly requested formats. This
configuration option will also work regardless of file extension because it looks for a matching pattern
string.
NOTE:
This will also work for TOML but we recommend using version_toml for TOML files as it actually will
interpret the TOML file and replace the version number before writing the file back to disk.
This is a comprehensive list (but not all variations) of examples where the following versions will be
matched and replaced by the new version:
# Common variable declaration formats
version='1.2.3'
version = "1.2.3"
release = "v1.2.3" # if tag_format is set
# YAML
version: 1.2.3
# JSON
"version": "1.2.3"
# NPM & GitHub Actions YAML
version@1.2.3
version@v1.2.3 # if tag_format is set
# Walrus Operator
version := "1.2.3"
# Excessive whitespace
version = '1.2.3'
# Mixed Quotes
"version" = '1.2.3'
# Custom Tag Format with tag_format set (monorepos)
__release__ = "module-v1.2.3"
IMPORTANT:
The Regular Expression expects a version value to exist in the file to be replaced. It cannot be an
empty string or a non-semver compliant string. If this is the very first time you are using PSR, we
recommend you set the version to 0.0.0.
This may become more flexible in the future with resolution of issue #941.
WARNING:
If the file (ex. JSON) you are replacing has two of the same variable name in it, this pattern match
will not be able to differentiate between the two and will replace both. This is a limitation of the
pattern matching and not a bug.
Default: []
Commit Parsing
One of the core components of Python Semantic Release (PSR) is the commit parser. The commit parser is
responsible for parsing a Project's Git Repository commit history to extract insights about project
changes and make decisions based on this insight.
The primary decision that PSR makes based on the commit history is whether or not to release a new
version of the project, and if so, what version number to release. This decision is made based on the
commit message descriptions of the change impact introduced by the commit. The change impact describes
the impact to the end consumers of the project. Depending on the type of change, the version number will
be incremented according to the Semantic Versioning specification (semver). It is the commit parser's
job to extract the change impact from the commit message to determine the severity of the changes and
then subsequently determine the semver level that the version should be bumped to for the next release.
The commit parser is also responsible for interpreting other aspects of the commit message which can be
used to generate a helpful and detailed changelog. This includes extracting the type of change, the scope
of the change, any breaking change descriptions, any linked pull/merge request numbers, and any linked
issue numbers.
PSR provides several built-in commit parsers to handle a variety of different commit message styles. If
the built-in parsers do not meet your needs, you can write your own custom parser to handle your specific
commit message style.
WARNING:
PSR's built-in commit parsers are designed to be flexible enough to provide a convenient way to
generate the most effective changelogs we can, which means some 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 tandem with PSR, you should be aware of the differences in feature support and
fall back to the official format guidelines if necessary.
----
Built-in Commit Parsers
The following parsers are built in to Python Semantic Release:
• ConventionalCommitParser
• AngularCommitParser (deprecated in v9.19.0)
• EmojiCommitParser
• ScipyCommitParser
• TagCommitParser (deprecated in v9.12.0)
----
Conventional Commits Parser
Introduced in v9.19.0
A parser that is designed to parse commits formatted according to the Conventional Commits Specification.
The parser is implemented with the following logic in relation to how PSR's core features:
• Version Bump Determination: This parser extracts the commit type from the subject line of the commit
(the first line of a commit message). This type is matched against the configuration mapping to
determine the level bump for the specific commit. If the commit type is not found in the configuration
mapping, the commit is considered a non-parsable commit and will return it as a ParseError object and
ultimately a commit of type "unknown". The configuration mapping contains lists of commit types that
correspond to the level bump for each commit type. Some commit types are still valid do not trigger a
level bump, such as "chore" or "docs". You can also configure the default level bump
commit_parser_options.default_level_bump 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
changelog.exclude_commit_patterns to ignore those commit styles.
• Pull/Merge Request Identifier Detection: This parser implements PSR's Common 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 Common Issue Identifier 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 Common 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 commit_parser_options setting.
• Release Notice Footer Detection: This parser implements PSR's Common 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
defaults.
----
Angular Commit Parser
WARNING:
This parser was deprecated in v9.19.0. It will be removed in a future release. This parser is being
replaced by the Conventional Commits Parser.
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 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
commit_parser_options.default_level_bump 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 Angular
Commit Style Guidelines). 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
changelog.exclude_commit_patterns to ignore those commit styles.
• Pull/Merge Request Identifier Detection: This parser implements PSR's Common 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. Feature available in v9.13.0+.
• Linked Issue Identifier Detection: This parser implements PSR's Common Issue Identifier 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.
Feature available in v9.15.0+.
• Squash Commit Evaluation: This parser implements PSR's Common 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 commit_parser_options setting. Feature available in v9.17.0+.
• Release Notice Footer Detection: This parser implements PSR's Common 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 v9.18.0+.
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
defaults.
----
Emoji Commit Parser
A parser that is designed to parse commits formatted to the Gitmoji Specification with a few additional
features that the specification does not cover but provide similar functionality expected from a Semantic
Release tool. As the Gitmoji Specification describes, the emojis can be specified in either the unicode
format or the shortcode text format. See the Gitmoji Specification for the pros and cons for which format
to use, but regardless, the configuration options must match the format used in the commit messages. The
parser is implemented with the following logic in relation to 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 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
priority order. If no emoji is found in the subject line, the commit is classified as other and will
default to the level bump defined by the configuration option commit_parser_options.default_level_bump.
• Changelog Generation: PSR will group commits in the changelog by the emoji type used in the commit
message. The emoji is used as the version section title and the commit descriptions are listed under
that section. No emojis are removed from the commit message so each will be listed in the changelog and
release notes. When more than one emoji is found in the subject line of a commit, the emoji with the
highest priority is the one that will influence the grouping of the commit in the changelog. Commits
containing no emojis or non-configured emojis are consolidated into an "Other" section. To remove
unwanted commits from the changelog that would normally be added into the "other" section, consider the
use of the configuration option changelog.exclude_commit_patterns to ignore those commit styles.
• Pull/Merge Request Identifier Detection: This parser implements PSR's Common 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. Feature available in v9.13.0+.
• Linked Issue Identifier Detection: [Disabled by default] This parser implements PSR's Common Issue
Identifier 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. This feature is disabled by default since it is not a part of the Gitmoji
Specification but can be 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 Common 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 commit_parser_options setting. Feature available in v9.17.0+.
• Release Notice Footer Detection: This parser implements PSR's Common 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 v9.18.0+.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in
defaults.
----
Scipy Commit Parser
A parser that is designed to parse commits formatted according to the 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 Angular Commit Parser parser with
pre-defined scipy commit types 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
defaults.
----
Tag Commit Parser
WARNING:
This parser was deprecated in v9.12.0. It will be removed in a future release.
The original parser from v1.0.0 of Python Semantic Release. Similar to the emoji parser above, but with
less features.
If no commit parser options are provided via the configuration, the parser will use PSR's built-in
defaults.
----
Common Linked Merge Request Detection
Introduced in v9.13.0
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 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.
Examples:
All of the following will extract a MR number of "x123", where 'x' is the character prefix
1. BitBucket: Merged in feat/my-awesome-feature (pull request #123)
2. GitHub: feat: add new feature (#123)
3. GitLab: fix: resolve an issue (!123)
----
Common Issue Identifier Detection
Introduced in v9.15.0
All of the PSR built-in parsers implement common issue identifier detection logic, which is similar to
many VCS platforms such as GitHub, GitLab, and BitBucket. The parsers will look for common issue closure
text prefixes in the Git Trailer format in the commit message to identify and extract issue numbers. The
detection logic is not strict to any specific issue tracker as we try to provide a flexible approach to
identifying issue numbers but in order to be flexible, it is required to the use the Git Trailer format
with a colon (:) as the token separator.
PSR attempts to support all variants of issue closure text prefixes, but not all will work for your VCS.
PSR supports the following case-insensitive prefixes and their conjugations (plural, present, & past
tense):
• close (closes, closing, closed)
• fix (fixes, fixing, fixed)
• resolve (resolves, resolving, resolved)
• 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 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:
• comma-separated (ex. Closes: #123, #456, #789)
• space-separated (ex. resolve: #123 #456 #789)
• semicolon-separated (ex. Fixes: #123; #456; #789)
• slash-separated (ex. close: #123/#456/#789)
• ampersand-separated (ex. Implement: #123 & #789)
• and-separated (ex. Resolve: #123 and #456 and #789)
• mixed (ex. Closed: #123, #456, and #789 or Fixes: #123, #456 & #789)
All the examples above use the most common issue number prefix (#) but PSR is flexible to support other
prefixes used by VCS platforms or issue trackers such as JIRA (ex. ABC-###).
The parsers will return a tuple of issue numbers as strings if any are found in the commit message.
Strings are returned to ensure that the any issue number prefix characters are preserved (ex. #123 or
ABC-123). If no issue numbers are found, the parsers will return an empty tuple.
References:
• BitBucket: Resolving Issues Automatically
• GitHub: Linking Issue to PR
• GitLab: Default Closing Patterns
----
Common Release Notice Footer Detection
Introduced in v9.18.0*
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
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.
----
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 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.
Example:
The following example will extract three separate commit messages from a single GitHub formatted squash
commit message of conventional commit style:
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 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:
## 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 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.
----
Customization
Each of the built-in parsers can be customized by providing overrides in the commit_parser_options
setting of the configuration file. This can be used to toggle parsing features on and off or to add,
modify, or remove the commit types that are used to determine the level bump for a commit. Review the API
documentation for the specific parser's options class to see what changes to the default behavior can be
made.
----
Custom Parsers
Custom parsers can be written to handle commit message styles that are not covered by the built-in
parsers or by option customization of the built-in parsers.
Python Semantic Release provides several building blocks to help you write your parser. To maintain
compatibility with how Python Semantic Release will invoke your parser, you should use the appropriate
object as described below, or create your own object as a subclass of the original which maintains the
same interface. Type parameters are defined where appropriate to assist with static type-checking.
The commit_parser option, if set to a string which does not match one of Python Semantic Release's
built-in commit parsers, will be used to attempt to dynamically import a custom commit parser class.
In order to use your custom parser, you must provide how to import the module and class via the
configuration option. There are two ways to provide the import string:
1. File Path & Class: The format is "path/to/module_file.py:ClassName". This is the easiest way to
provide a custom parser. This method allows you to store your custom parser directly in the repository
with no additional installation steps. PSR will locate the file, load the module, and instantiate the
class. Relative paths are recommended and it should be provided relative to the current working
directory. This import variant is available in v9.16.0 and later.
2. Module Path & Class: The format is "package.module_name:ClassName". This method allows you to store
your custom parser in a package that is installed in the same environment as PSR. This method is
useful if you want to share your custom parser across multiple repositories. To share it across
multiple repositories generally you will need to publish the parser as its own separate package and
then pip install it into the current virtual environment. You can also keep it in the same repository
as your project as long as it is in the current directory of the virtual environment and is locatable
by the Python import system. You may need to set the PYTHONPATH environment variable if you have a
more complex directory structure. This import variant is available in v8.0.0 and later.
To test that your custom parser is importable, you can run the following command in the directory
where PSR will be executed:
python -c "from package.module_name import ClassName"
NOTE:
Remember this is basic python import rules so the package name is optional and generally packages
are defined by a directory with __init__.py files.
Tokens
The tokens built into Python Semantic Release's commit parsing mechanism are inspired by both the
error-handling mechanism in Rust's error handling and its implementation in black. It is documented that
catching exceptions in Python is slower than the equivalent guard implemented using if/else checking when
exceptions are actually caught, so although try/except blocks are cheap if no exception is raised, commit
parsers should always return an object such as ParseError instead of raising an error immediately. This
is to avoid catching a potentially large number of parsing errors being caught as the commit history of a
repository is being parsed. Python Semantic Release does not raise an exception if a commit cannot be
parsed.
Python Semantic Release uses ParsedCommit as the return type of a successful parse operation, and
ParseError as the return type from an unsuccessful parse of a commit. You should review the API
documentation linked to understand the fields available on each of these objects.
It is important to note, the ParseError implements an additional method, raise_error. This method raises
a CommitParseError with the message contained in the error field, as a convenience.
In Python Semantic Release, the type semantic_release.commit_parser.token.ParseResult is defined as
ParseResultType[ParsedCommit, ParseError], as a convenient shorthand.
ParseResultType is a generic type, which is the Union of its two type parameters. One of the types in
this union should be the type returned on a successful parse of the commit, while the other should be the
type returned on an unsuccessful parse of the commit.
A custom parser result type, therefore, could be implemented as follows:
• MyParsedCommit subclasses ParsedCommit
• MyParseError subclasses ParseError
• MyParseResult = ParseResultType[MyParsedCommit, MyParseError]
Internally, Python Semantic Release uses isinstance() to determine if the result of parsing a commit was
a success or not, so you should check that your custom result and error types return True from
isinstance(<object>, ParsedCommit) and isinstance(<object>, ParseError) respectively.
While it's not advisable to remove any of the fields that are available in the built-in token types,
currently only the bump field of the successful result type is used to determine how the version should
be incremented as part of this release. However, it's perfectly possible to add additional fields to your
tokens which can be populated by your parser; these fields will then be available on each commit in your
changelog template, so you can make additional information available.
Parser Options
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 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 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.
Commit Parsers
The commit parsers that are built into Python Semantic Release implement an instance method called parse,
which takes a single parameter commit of type git.objects.commit.Commit, and returns the type
ParseResultType.
To be compatible with Python Semantic Release, a commit parser must subclass CommitParser. A subclass
must implement the following:
• A class-level attribute parser_options, which must be set to ParserOptions or a subclass of this.
• An __init__ method which takes a single parameter, options, that should be of the same type as the
class' parser_options attribute.
• A method, parse, which takes a single parameter commit that is of type git.objects.commit.Commit, and
returns ParseResult, or a subclass of this.
By default, the constructor for 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 be a good idea to perform
this logic during parser instantiation rather than inside the parse method. The parse method will be
called once per commit in the repository's history during parsing, so the effect of slow parsing logic
within the parse method will be magnified significantly for projects with sizeable Git histories.
Commit Parsers have two type parameters, "TokenType" and "OptionsType". The first is the type which is
returned by the parse method, and the second is the type of the "options" class for this parser.
Therefore, a custom commit parser could be implemented via:
class MyParserOptions(semantic_release.ParserOptions):
def __init__(self, message_prefix: str) -> None:
self.prefix = message_prefix * 2
class MyCommitParser(
semantic_release.CommitParser[semantic_release.ParseResult, MyParserOptions]
):
def parse(self, commit: git.objects.commit.Commit) -> semantic_release.ParseResult:
...
Version Change Reports
When using the semantic-release version and semantic-release changelog commands, Python Semantic Release
(PSR) will generate a changelog and release notes for your project automatically in the default
configuration. The changelog is rendered using the Jinja template engine, and in the default
configuration, PSR will use a built-in template file to render the changelog at the file location defined
by the changelog_file setting.
Through the use of the templating engine & the template_dir configuration setting, you can customize the
appearance of your changelog and release notes content. You may also generate a set of files using your
custom template directory and the templates will be rendered relative to the root of your repository.
Because PSR uses a third-party library, Jinja, as its template engine, we do not include all the syntax
within our documentation but rather you should refer to the Template Designer Documentation for guidance
on how to customize the appearance of your release files. If you would like to customize the template
environment itself, then certain options are available to you via changelog environment configuration.
If you do not want to use the changelog generation features, you can disable changelog generation
entirely during the semantic-release version command by providing the --no-changelog command-line option.
Using the Default Changelog
If you don't provide any custom templates in the changelog.template_dir, the default changelog templates
will be used to render the changelog.
PSR provides two default changelog output formats:
1. Markdown (.md), default
2. reStructuredText (.rst), available since v9.11.0
Both formats are kept in sync with one another to display the equivalent information in the respective
format. The default changelog template is located in the data/templates/ directory within the PSR
package. The templates are written in modular style (ie. multiple files) and during the render process
are ultimately combined together to render the final changelog output. The rendering start point is the
CHANGELOG.{FORMAT_EXT}.j2 underneath the respective format directory.
PSR provides a few configuration options to customize the default changelog output and can be found under
the changelog.default_templates section as well as some common configuration options under the changelog
section.
To toggle the output format, you only need to set the changelog.default_templates.changelog_file file
name to include the desired file extension (.md or .rst). If you would like a different extension for the
resulting changelog file, but would like to still have control over the template format, you can set the
changelog.default_templates.output_format configuration setting to the desired format.
A common and highly-recommended configuration option is the 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 conventional commit standard) and only include the important changes that impact the consumer
of your software.
Another important configuration option is the changelog.mode setting which determines the behavior of the
changelog generation. There are 2 modes that available that described in detail below.
1. Initialization Mode when mode = "init".
2. Update Mode when mode = "update".
Initialization Mode
When using the initialization mode, the changelog file will be created from scratch using the entire git
history and overwrite any existing changelog file. This is the default behavior introduced in v8.0.0.
This is useful when you are trying to convert over to Python Semantic Release for the first time or when
you want to automatically update the entire format of your changelog file.
WARNING:
If you have an existing changelog in the location you have configured with the
changelog.changelog_file setting, PSR will overwrite the contents of this file on each release.
Please make sure to refer to Migrating an Existing Changelog.
Update Mode
NOTE:
Introduced in v9.10.0.
When using the update mode, only the change information from the last release will be prepended into the
existing changelog file (defined by the changelog.changelog_file). This mimics the behavior that was used
in versions prior to v8.0.0 before the conversion to a templating engine but now uses the Jinja to
accomplish the update. This mode is best suited for managing changes over the lifetime of your project
when you may have a need to make manual changes or adjustments to the changelog and its not easily
recreated with a template.
How It Works
In order to insert the new release information into an existing changelog file, your changelog file must
have an insertion flag to indicate where the new release information should be inserted. The default
template will read in your existing changelog file, split the content based on the insertion flag, and
then recombine the content (including the insertion flag) with the new release information added after
the insertion flag.
The insertion flag is customizable through the changelog.insertion_flag setting. Generally, your
insertion flag should be unique text to your changelog file to avoid any unexpected behavior. See the
examples below.
In the case where the insertion flag is NOT found in the existing changelog file, the changelog file will
be re-written without any changes.
If there is no existing changelog file found, then the changelog file will be initialized from scratch as
if the mode was set to init, except the changelog.insertion_flag will be included into the newly created
changelog file.
TIP:
We have accomplished changelog updating through the use of the Jinja templating and additional context
filters and context variables. This is notable because in the case that you want to customize your
changelog template, you now can use the same logic to enable changelog updates of your custom
template!
SEE ALSO:
• Migrating an Existing Changelog.
Example
Given your existing changelog looks like the following with a changelog.insertion_flag set to <!--
version list -->, when you run the semantic-release version command, the new release information will be
inserted after the insertion flag.
Before
# CHANGELOG
<!-- version list -->
## 1.0.0
- Initial Release
After
# CHANGELOG
<!-- version list -->
## v1.1.0
### Feature
- feat: added a new feature
### Fix
- fix: resolved divide by zero error
## 1.0.0
- Initial Release
Configuration Examples
1. Goal: Configure an updating reStructuredText changelog with a custom insertion flag within
pyproject.toml.
[tool.semantic_release.changelog]
mode = "update"
insertion_flag = "..\n All versions below are listed in reverse chronological order"
[tool.semantic_release.changelog.default_templates]
changelog_file = "CHANGELOG.rst"
output_format = "rst" # optional because of the file extension
2. Goal: Configure an updating Markdown changelog with custom file name and default insertion flag within
a separate config file releaserc.json.
{
"semantic_release": {
"changelog": {
"mode": "update",
"default_templates": {
"changelog_file": "docs/HISTORY",
"output_format": "md"
}
}
}
}
3. Goal: Configure an initializing reStructuredText changelog with filtered conventional commits patterns
and merge commits within a custom config file releaserc.toml.
[semantic_release.changelog]
mode = "init"
default_templates = { changelog_file = "docs/CHANGELOG.rst" }
exclude_commit_patterns = [
'''chore(?:\([^)]*?\))?: .+''',
'''ci(?:\([^)]*?\))?: .+''',
'''refactor(?:\([^)]*?\))?: .+''',
'''style(?:\([^)]*?\))?: .+''',
'''test(?:\([^)]*?\))?: .+''',
'''build\((?!deps\): .+)''',
'''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 commit parsing section to see how to
write commit messages that will be properly parsed and displayed in these sections.
Using the Default Release Notes
PSR has the capability to generate release notes as part of the publishing of a new version similar to
the changelog. The release notes are generated using a Jinja template and posted to the your remote
version control server (VCS) such as GitHub, GitLab, etc during the semantic-release version command. PSR
provides a 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 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):
# 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 mask_initial_release setting and will also add a
comparison link to the previous release if one exists without customization.
As of v9.18.0, 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.
SEE ALSO:
• To personalize your release notes, see the Custom Release Notes section.
Custom Changelogs
If you would like to customize the appearance of your changelog, you can create your own custom templates
and configure PSR to render your templates instead during the semantic-release version and
semantic-release changelog commands.
To use a custom template, you need to create a directory within your repository and set the template_dir
setting to the name of this directory. The default name is "templates".
Templates are identified by giving a .j2 extension to the template file. Any such templates have the .j2
extension removed from the target file. Therefore, to render an output file foo.csv, you should create a
template called foo.csv.j2 within your template directory.
If you have additional files that you would like to render alongside your changelog, you can place these
files within the template directory. A file within your template directory which does not end in .j2 will
not be treated as a template; it will be copied to its target location without being rendered by the
template engine.
TIP:
Hidden files within the template directory (i.e. filenames that begin with a period ".") are excluded
from the rendering process. Hidden folders within the template directory are also excluded, along with
all files and folders contained within them. This is useful for defining macros or other template
components that should not be rendered individually.
TIP:
When initially starting out at customizing your own changelog templates, you should reference the
default template embedded within PSR. The template directory is located at data/templates/ within the
PSR package. Within our templates directory we separate out each type of commit parser (e.g. angular)
and the content format type (e.g. markdown). You can copy this directory to your repository's
templates directory and then customize the templates to your liking.
Directory Structure
When the templates are rendered, files within the templates directory tree are output to the location
within your repository that has the same relative path to the root of your project as the relative path
of the template within the templates directory.
Example
An example project has the following structure:
example-project/
├── src/
│ └── example_project/
│ └── __init__.py
└── ch-templates/
├── CHANGELOG.md.j2
├── .components/
│ └── authors.md.j2
├── .macros.j2
├── src/
│ └── example_project/
│ └── data/
│ └── data.json.j2
└── static/
└── config.cfg
And a custom templates folder configured via the following snippet in pyproject.toml:
[tool.semantic_release.changelog]
template_dir = "ch-templates"
After running a release with Python Semantic Release, the directory structure of the project will now
look like this (excluding the template directory):
example-project/
├── CHANGELOG.md
├── src/
│ └── example_project/
│ ├── data/
│ │ └── data.json
│ └── __init__.py
└── static/
└── config.cfg
Importantly, note the following:
• There is no top-level .macros file created, because hidden files are excluded from the rendering
process.
• There is no top-level .components directory created, because hidden folders and all files and folders
contained within it are excluded from the rendering process.
• The .components/authors.md.j2 file is not rendered directly, however, it is used as a component to the
CHANGELOG.md.j2 via an include statement in the changelog template.
• To render data files into the src/ folder, the path to which the template should be rendered has to be
created within the ch-templates directory.
• The ch-templates/static folder is created at the top-level of the project, and the file
ch-templates/static/config.cfg is copied, not rendered to the new top-level static folder.
You may wish to leverage this behavior to modularize your changelog template, to define macros in a
separate file, or to reference static data which you would like to avoid duplicating between your
template environment and the remainder of your project.
Changelog Template Context
During the rendering of a directory tree, Python Semantic Release provides information about the history
of the project available within the templating environment in order for it to be used to generate the
changelog and other desired documents.
Important project information is provided to the templating environment through the global variable
context or ctx for short. Within the template environment, the context object has the following
attributes:
• changelog_insertion_flag (str): the insertion flag used to determine where the new release information
should be inserted into the changelog file. This value is passed directly from
changelog.insertion_flag.
Introduced in v9.10.0.
Example Usage:
{% set changelog_parts = prev_changelog_contents.split(
ctx.changelog_insertion_flag, maxsplit=1
)
%}
• changelog_mode (Literal["init", "update"]): the mode of the changelog generation currently being used.
This can be used to determine different rendering logic. This value is passed directly from the
changelog.mode configuration setting.
Introduced in v9.10.0.
Example Usage:
{% if ctx.changelog_mode == "init"
%}{% include ".changelog_init.md.j2"
%}{#
#}{% elif ctx.changelog_mode == "update"
%}{% include ".changelog_update.md.j2"
%}{#
#}{% endif
%}
• history (ReleaseHistory): the ReleaseHistory instance for the project (See the Release History section
for more information).
Example Usage:
{% set unreleased_commits = ctx.history.unreleased | dictsort
%}{% for release in context.history.released.values()
%}{% include ".versioned_changes.md.j2"
#}{% endfor
%}
• hvcs_type (str): the name of the VCS server type currently configured. This can be used to determine
which filters are available or different rendering logic.
Introduced in v9.6.0.
Example Usage:
{% if ctx.hvcs_type == "github"
%}{{ "29" | pull_request_url
}}{#
#}{% elif ctx.hvcs_type == "gitlab"
%}{{ "29" | merge_request_url
}}{#
#}{% endif
%}
• mask_initial_release (bool): a boolean value indicating whether the initial release should be masked
with a generic message. This value is passed directly from the
changelog.default_templates.mask_initial_release configuration setting.
Introduced in v9.14.0.
Example Usage:
#}{% if releases | length == 1 and ctx.mask_initial_release
%}{# # On a first release, generate a generic message
#}{% include ".components/first_release.md.j2"
%}{% else
%}{# # Not the first release
#}{% include ".components/versioned_changes.md.j2"
%}{% endif
%}
• repo_name (str): the name of the current repository parsed from the Git url.
Example Usage:
{{ ctx.repo_name }}
example_repo
• repo_owner (str): the owner of the current repository parsed from the Git url.
Example Usage:
{{ ctx.repo_owner }}
example_org
• prev_changelog_file (str): the path to the previous changelog file that should be updated with the new
release information. This value is passed directly from changelog.changelog_file.
Introduced in v9.10.0.
Example Usage:
{% set prev_changelog_contents = prev_changelog_file | read_file | safe %}
Release History
A ReleaseHistory object has two attributes: released and unreleased.
The unreleased attribute is of type Dict[str, List[ParseResult]]. Each commit in the current branch's
commit history since the last release on this branch is grouped by the type attribute of the ParsedCommit
returned by the commit parser, or if the parser returned a ParseError then the result is grouped under
the "unknown" key.
For this reason, every element of ReleaseHistory.unreleased["unknown"] is a ParseError, and every element
of every other value in ReleaseHistory.unreleased is of type ParsedCommit.
Typically, commit types will be "feature", "fix", "breaking", though the specific types are determined by
the parser. For example, the EmojiCommitParser uses a textual representation of the emoji corresponding
to the most significant change introduced in a commit (e.g. ":boom:") as the different commit types. As a
template author, you are free to customize how these are presented in the rendered template.
NOTE:
If you are using a custom commit parser following the guide at Custom Parsers, your custom
implementations of ParseResult, ParseError and ParsedCommit will be used in place of the built-in
types.
The released attribute is of type Dict[Version, Release]. The keys of this dictionary correspond to each
version released within this branch's history, and are of type Version. You can use the as_tag() method
to render these as the Git tag that they correspond to inside your template.
A Release object has an elements attribute, which has the same structure as the unreleased attribute of a
ReleaseHistory; that is, elements is of type Dict[str, List[ParseResult]], where every element of
elements["unknown"] is a ParseError, and elements of every other value correspond to the type attribute
of the ParsedCommit returned by the commit parser.
The commits represented within each ReleaseHistory.released[version].elements grouping are the commits
which were made between version and the release corresponding to the previous version. That is, given two
releases Version(1, 0, 0) and Version(1, 1, 0), ReleaseHistory.released[Version(1, 0, 0)].elements
contains only commits made after the release of Version(1, 0, 0) up to and including the release of
Version(1, 1, 0).
To maintain a consistent order of subsections in the changelog headed by the commit type, it's
recommended to use Jinja's dictsort filter.
Each Release object also has the following attributes:
• tagger: git.Actor: The tagger who tagged the release.
• committer: git.Actor: The committer who made the release commit.
• tagged_date: datetime: The date and time at which the release was tagged.
SEE ALSO:
• Built-in Commit Parsers
• Commit Parser Tokens
• git.Actor
• datetime.strftime Format Codes
Changelog Template Filters
In addition to the context variables, PSR seeds the template environment with a set of custom functions
(commonly called filters in Jinja terminology) for use within the template. Filter's first argument is
always piped (|) to the function while any additional arguments are passed in parentheses like normal
function calls.
The filters provided vary based on the VCS configured and available features:
• autofit_text_width (Callable[[textStr, maxWidthInt, indent_sizeInt], textStr]): given a text string,
fit the text to the maximum width provided. This filter is useful when you want to wrap text to a
specific width. The filter will attempt to break the text at word boundaries and will indent the text
by the amount specified in the indent_size parameter.
Introduced in v9.12.0.
Example Usage:
{{ "This is a long string that needs to be wrapped to a specific width" | autofit_text_width(40, 4) }}
Markdown Output:
This is a long string that needs to be
wrapped to a specific width
• convert_md_to_rst (Callable[[MdStr], RstStr]): given a markdown string, convert it to reStructuredText
format. This filter is useful when building a reStructuredText changelog but your commit messages are
in markdown format. It is utilized by the default RST changelog template. It is limited in its ability
to convert all markdown to reStructuredText, but it handles most common cases (bold, italics,
inline-raw, etc.) within commit messages.
Introduced in v9.11.0.
Example Usage:
{{ "\n* %s (`%s`_)\n" | format(
commit.message.rstrip() | convert_md_to_rst,
commit.short_hash,
)
}}
• 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 v9.18.0.
Example Usage:
{{ "example-package" | create_pypi_url }}
{{ "example-package" | create_pypi_url("1.0.0") }}
Markdown Output:
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 v9.18.0.
Example Usage:
{{ "v1.0.0" | create_release_url }}
Markdown Output:
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 resulting url. Parameter
order is as described above respectively.
Introduced in v9.6.0.
Example Usage:
{{ "example/repo.git" | create_server_url }}
{{ "example/repo" | create_server_url(None, "results=1", "section-header") }}
Markdown Output:
https://example.com/example/repo.git
https://example.com/example/repo?results=1#section-header
• create_repo_url (Callable[[RepoPathStr, QueryStr | None, FragmentStr | None], UrlStr]): when given a
repository path, prepend the configured vcs server host, and repo namespace. Optionally you can
provide, an additional query string and/or a url fragment to also put in the url. Parameter order is as
described above respectively. This is similar to create_server_url but includes the repo namespace and
owner automatically.
Introduced in v9.6.0.
Example Usage:
{{ "releases/tags/v1.0.0" | create_repo_url }}
{{ "issues" | create_repo_url("q=is%3Aissue+is%3Aclosed") }}
Markdown Output:
https://example.com/example/repo/releases/tags/v1.0.0
https://example.com/example/repo/issues?q=is%3Aissue+is%3Aclosed
• commit_hash_url (Callable[[hashStr], UrlStr]): given a commit hash, return a URL to the commit in the
remote.
Introduced in v8.0.0.
Example Usage:
{{ commit.hexsha | commit_hash_url }}
Markdown Output:
https://example.com/example/repo/commit/a1b2c3d435657f5d339ba10c7b1ed81b460af51d
• compare_url (Callable[[StartRefStr, StopRefStr], UrlStr]): given a starting git reference and a ending
git reference create a comparison url between the two references that can be opened on the remote
Introduced in v9.6.0.
Example Usage:
{{ "v1.0.0" | compare_url("v1.1.0") }}
Markdown Output:
https://example.com/example/repo/compare/v1.0.0...v1.1.0
• issue_url (Callable[[IssueNumStr | IssueNumInt], UrlStr]): given an issue number, return a URL to the
issue on the remote vcs. In v9.12.2, this filter was updated to handle a string that has leading prefix
symbols (ex. #32) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{# Add Links to issues annotated in the commit message
# NOTE: commit.linked_issues is only available in v9.15.0 or greater
#
#}{% for issue_ref in commit.linked_issues
%}{{ "- [%s](%s)" | format(issue_ref, issue_ref | issue_url)
}}{% endfor
%}
Markdown Output:
- [#32](https://example.com/example/repo/issues/32)
• merge_request_url (Callable[[MergeReqStr | MergeReqInt], UrlStr]): given a merge request number, return
a URL to the merge request in the remote. This is an alias to the pull_request_url but only available
for the VCS that uses the merge request terminology. In v9.12.2, this filter was updated to handle a
string that has leading prefix symbols (ex. #29) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{{
"[%s](%s)" | format(
commit.linked_merge_request,
commit.linked_merge_request | merge_request_url
)
}}
{# commit.linked_merge_request is only available in v9.13.0 or greater #}
Markdown Output:
[#29](https://example.com/example/repo/-/merge_requests/29)
• pull_request_url (Callable[[PullReqStr | PullReqInt], UrlStr]): given a pull request number, return a
URL to the pull request in the remote. For remote vcs' that use merge request terminology, this filter
is an alias to the merge_request_url filter function. In v9.12.2, this filter was updated to handle a
string that has leading prefix symbols (ex. #29) and will strip the prefix before generating the URL.
Introduced in v9.6.0, Modified in v9.12.2.
Example Usage:
{# Create a link to the merge request associated with the commit
# NOTE: commit.linked_merge_request is only available in v9.13.0 or greater
#}{{
"[%s](%s)" | format(
commit.linked_merge_request,
commit.linked_merge_request | pull_request_url
)
}}
Markdown Output:
[#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 v9.18.0.
Example Usage:
{{ "%s Releases" | format_w_official_vcs_name }}
{{ "{} Releases" | format_w_official_vcs_name }}
{{ "{vcs_name} Releases" | format_w_official_vcs_name }}
Markdown Output:
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 file into the templating environment to be updated.
Introduced in v9.10.0.
Example Usage:
{% 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:
{{ ["#222", "#1023", "#444"] | sort_numerically }}
{{ ["#222", "#1023", "#444"] | sort_numerically(True) }}
Markdown Output:
['#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_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 │ ✅ │ ✅ │ ✅ │ ✅ │
└────────────────────────────┴───────────┴───────┴────────┴────────┘
SEE ALSO:
• Filters
Example
The following template is a simple example of how to render a changelog using the PSR template context to
create a changelog in Markdown format.
Configuration: pyproject.toml
[tool.semantic_release.changelog]
template_dir = "templates"
Template: templates/CHANGELOG.md.j2
# CHANGELOG
{% for version, release in ctx.history.released.items()
%}{{
"## %s (%s)" | format(version.as_tag(), release.tagged_date.strftime("%Y-%m-%d"))
}}{% for type_, commits in release["elements"] if type_ != "unknown" | dictsort
%}{{
"### %s" | format(type_ | title)
}}{% for commit in commits
%}{{
"* %s ([`%s`](%s))" | format(
commit.descriptions[0] | capitalize,
commit.hexsha[:7],
commit.hexsha | commit_hash_url,
)
}}{% endfor
%}{% endfor
%}{% endfor
%}
Result: CHANGELOG.md
# CHANGELOG
## v1.1.0 (2022-01-01)
### Feature
* Added a new feature ([`a1b2c3d`](https://github.com/example/repo/commit/a1b2c3d))
## v1.0.0 (2021-12-31)
### Fix
* Resolved divide by zero error ([`e4f5g6h`](https://github.com/example/repo/commit/e4f5g6h))
It is important to note that the template utilizes the context variable to extract the project history as
well as the commit_hash_url filter to generate a URL to the remote VCS for each commit. Both of these are
injected into the template environment by PSR.
Custom Release Notes
If you would like to customize the appearance of your release notes, you can add a hidden file named
.release_notes.md.j2 at the root of your changelog.template_dir. This file will automatically be detected
and used to render the release notes during the semantic-release version and semantic-release changelog
commands.
A similar template rendering mechanism is used to render the release notes as is used for the changelog.
There are minor differences in the context available to the release notes template but the template
directory structure and modularity is maintained.
TIP:
When initially starting out at customizing your own release notes template, you should reference the
default template embedded within PSR. The release notes template can be found in the directory
data/templates/<parser>/md within the PSR package.
Release Notes Context
All of the changelog's template context is exposed to the Jinja template when rendering the release
notes.
Additionally, the following two globals are available to the template:
• release (Release): contains metadata about the content of the release, as parsed from commit logs
Introduced in v8.0.0.
• version (Version): contains metadata about the software version to be released and its git tag
Introduced in v8.0.0.
Example
Below is an example template that can be used to render release notes (it's similar to GitHub's ‐
automatically generated release notes):
Configuration: pyproject.toml
[tool.semantic_release.changelog]
template_dir = "templates"
Template: templates/.release_notes.md.j2
## What's Changed
{% for type_, commits in release["elements"] | dictsort
%}{%- if type_ != "unknown"
%}{{
"### %s" | format(type_ | title)
}}{% for commit in commits
%}{{
"* %s by %s in [`%s`](%s)" | format(
commit.descriptions[0] | capitalize,
commit.commit.author.name,
commit.hexsha[:7],
commit.hexsha | commit_hash_url,
)
}}{%- endfor
%}{% endif
%}{% endfor
%}
Result: https://github.com/example/repo/releases/tag/v1.1.0
## What's Changed
### Feature
* Added a new feature by John Doe in [`a1b2c3d`](https://github.com/example/repo/commit/a1b2c3d)
Migrating an Existing Changelog
v9.10.0 or greater
Migrating an existing changelog is simple with Python Semantic Release! To preserve your existing
changelog, follow these steps:
1. Set the changelog.mode to "update" in your configuration file. This will ensure that only the new
release information is added to your existing changelog file.
2. Set the changelog.insertion_flag to a unique string. You may use the default value or set it to a
unique string that is not present in your existing changelog file. This flag is used to determine
where the new release information should be inserted into your existing changelog.
3. Add the insertion flag to your changelog file. This must match the value you set in step 2. The
insertion flag should be placed in the location above where you would like the new release information
to be inserted.
NOTE:
If you are trying to convert an existing changelog to a new format, you will need to do most of the
conversion manually (or rebuild via init and modify) and make sure to include your insertion flag into
the format of the new changelog.
Prior to v9.10.0
If you have an existing changelog that you would like to preserve, you will need to add the contents of
the changelog file to your changelog template - either directly or via Jinja's include tag.
If you would like only the history from your next release onwards to be rendered into the changelog in
addition to the existing changelog, you can add an if statement based upon the versions in the keys of
context.released.
Upgrading Templates
As PSR evolves, new features and improvements are added to the templating engine. If you have created
your own custom templates, you may need to update them to take advantage of some new features. Below are
some instructions on how to upgrade your templates to gain the benefits of the new features.
Incrementally Updating Changelog Template
NOTE:
This section is only relevant if you are upgrading from a version of PSR greater than v8.0.0 and prior
to v9.10.0 and have created your own custom templates.
If you have previously created your own custom templates and would like to gain the benefits of the new
updating changelog feature, you will need to make a few changes to your existing templates.
The following steps are a few suggestions to help upgrade your templates but primarily you should review
the embedded default templates in the PSR package for a full example. You can find the default templates
at data/templates/ directory.
1. Add a conditional to check the changelog_mode. This will allow you to determine if you should render
the entire changelog or just the new release information. See data/templates/*/md/CHANGELOG.md.j2 for
reference.
2. Use the new read_file filter to read in the existing changelog file ctx.prev_changelog_file. This will
allow you to include the existing changelog content in your new changelog file. See
data/templates/*/md/.components/changelog_update.md.j2 for reference.
3. Split the changelog content based on the insertion flag. This will allow you to insert the new release
information after the insertion flag (ctx.changelog_insertion_flag). See
data/templates/*/md/.components/changelog_update.md.j2 for reference.
4. Print the leading content before the insertion flag. This ensures you maintain any content that should
be included before the new release information. See
data/templates/*/md/.components/changelog_update.md.j2 for reference.
5. Print your insertion flag. This is imperative to ensure that the resulting changelog can be updated in
the future. See data/templates/*/md/.components/changelog_update.md.j2 for reference.
6. Print the new release information. Be sure to consider both unreleased and released commits during
this step because of the semantic-release changelog command that can be run at any time. See
data/templates/*/md/.components/changelog_update.md.j2 for reference.
7. Print the trailing content after the insertion flag. This ensures you maintain any content that should
be included after the new release information. See
data/templates/*/md/.components/changelog_update.md.j2 for reference.
TIP:
Modularity of your templates is key to handling both modes of changelog generation. Reference the
default templates for examples on how we handle both modes and defensively handle numerous breaking
scenarios.
TIP:
If you are having trouble upgrading your templates, please post a question on the PSR GitHub
Multibranch Releases
Python Semantic Release supports releases from multiple branches within your Git repository. You can
elect to have a branch or set of branches create releases or prereleases. There are no restrictions
enforced on how you set up your releases, but be aware that if you create new releases from multiple
branches, or prereleases from multiple independent branches using the same prerelease token, there is a
chance that Python Semantic Release will calculate the next version to be the same on more than one
branch (leading to an error that a Git tag already exists).
NOTE:
A "prerelease token" is the string used to suffix onto the 3-digit form of a full semantic version.
For example, in the version 1.2.3-beta.1, the prerelease token is "beta"
Typical strings used for pre-release tokens include "alpha", "beta", "dev" and "rc". These tend to
indicate a level of maturity of the software associated with the version, but the specific meaning of
each string is up to the project to decide.
Generally, it's good practice to maintain a single branch from which full releases are made, and one
branch at a time for each type of prerelease (alpha, beta, rc, etc).
If you absolutely require tagging and (pre-)releases to take place from multiple branches where there's a
risk that tags could conflict between branches, you can use the --build-metadata command line argument to
attach additional information (such as the branch name) to the tag in order to uniquely distinguish it
from any other tags that might be calculated against other branches. Such a situation may occur in the
following scenario:
O ----------- O <---- feature-1
/ "feat: abc"
/
O -------- O --------------- O <---- main
v1.0.0 v1.1.0
\
O ----------- O <---- feature-2
"feat: 123"
Suppose that Python Semantic Release has been configured to use the same prerelease token "alpha" for all
feature-* branches, and the default tag format "v{version}". In this case, running a pre-release from
branch feature-1 will recognize that since the last release, 1.1.0, a feature has been introduced and
therefore the next tag to be applied to feature-1 will be v1.2.0-alpha.1.
However, suppose we then try to run a release against feature-2. This will also recognize that a feature
has been introduced against the last released version of v1.1.0 and therefore will try to create the tag
v1.2.0-alpha.1, leading to an error as this tag was already created against feature-1.
To get around this issue, you can pass the branch name as part of the build metadata:
semantic-release version --build-metadata $(git branch --show-current)
This would lead to the tag v1.2.0-alpha.1+feature-1 and v1.2.0-alpha.1+feature-2 being applied to
branches feature-1 and feature-2, respectively. Note that "build metadata MUST be ignored" per the semver
specification when comparing two versions, so these two prereleases would be considered equivalent
semantic versions, but when merged to the branch configured to produce full releases (main), if released
separately the changes from each branch would be released in two versions that would be considered
different according to the semver specification.
NOTE:
If you have tags in your Git repository that are not valid semantic versions (which have then been
formatted into your tag_format), these tags will be ignored for the purposes of calculating the next
version.
Configuring Multibranch Releases
Within your configuration file, you can create one or more groups of branches ("release groups") that
produce a certain type of release. Options are configured at the group level, and the group to use is
chosen based on the current branch name against which Python Semantic Release is running.
Each release group is configured as a nested mapping under the tool.semantic_release.branches key in
pyproject.toml, or the equivalent structure in other formats. the mapping requires a single key that is
used as a name for the release group, which can help to identify it in log messages but has no effect on
the behavior of the release. For example, Python Semantic Release has only one release group by default
with the name main.
Inside each release group, the following key-value pairs can be set:
┌──────────────────┬──────────┬─────────┬────────────────────────┐
│ Key │ Required │ Default │ Description │
├──────────────────┼──────────┼─────────┼────────────────────────┤
│ match │ Yes │ N/A │ A Python regular │
│ │ │ │ expression to match │
│ │ │ │ against the active │
│ │ │ │ branch's name. If the │
│ │ │ │ branch name matches │
│ │ │ │ the provided regular │
│ │ │ │ expression, then this │
│ │ │ │ release group is │
│ │ │ │ chosen to provide the │
│ │ │ │ other configuration │
│ │ │ │ settings available. │
├──────────────────┼──────────┼─────────┼────────────────────────┤
│ prerelease │ No │ false │ Whether or not │
│ │ │ │ branches in this │
│ │ │ │ release group should a │
│ │ │ │ prerelease instead of │
│ │ │ │ a full release │
├──────────────────┼──────────┼─────────┼────────────────────────┤
│ prerelease_token │ No │ rc │ If creating a │
│ │ │ │ prerelease, specify │
│ │ │ │ the string to be used │
│ │ │ │ as a prerelease token │
│ │ │ │ in any new versions │
│ │ │ │ created against this │
│ │ │ │ branch. │
└──────────────────┴──────────┴─────────┴────────────────────────┘
WARNING:
If two release groups have overlapping "match" patterns, i.e. a the name of a branch could
theoretically match both patterns, then the release group which is defined first in your configuration
file is used.
Because of this, it's recommended that you place release groups with more specific match patterns
higher up in your configuration file than those with patterns that would match a broader range of
branch names.
For example, suppose a project currently on version 1.22.4 is working on a new major version. The project
wants to create a branch called 2.x.x against which they will develop the new major version, and they
would like to create "release candidate" ("rc") prereleases from this branch. There are also a number of
new features to integrate, and the project has agreed that all such branches should be named according to
the convention next-{developer initials}-{issue number}, leading to branches named similarly to
next-bc-prj-123. The project would like to release with tags that include some way to identify the branch
and date on which the release was made from the tag.
This project would be able to leverage the following configuration to achieve the above requirements from
their release configuration:
[tool.semantic_release.branches.main]
match = "(main|master)"
prerelease = false
[tool.semantic_release.branches."2.x.x"]
match = "2.x.x"
prerelease = true
prerelease_token = "rc"
[tool.semantic_release.branches."2.x.x New Features"]
match = "next-\\w+-prj-\\d+"
prerelease = true
prerelease_token = "alpha"
In a CI pipeline, the following command would allow attaching the date and branch name to the versions
that are produced (note this example uses the UNIX date command):
semantic-release version \
--build-metadata "$(git branch --show-current).$(date +%Y%m%d)"
This would lead to versions such as 1.1.1+main.20221127 or 2.0.0-rc.4+2.x.x.20221201.
NOTE:
Remember that is always possible to override the release rules configured by using the
--major/--minor/--patch/--prerelease and --as-prerelease flags.
Automatic Releases
The key point with using this package is to automate your releases and stop worrying about version
numbers. Different approaches to automatic releases and publishing with the help of this package can be
found below. Using a CI is the recommended approach.
Guides
Setting up python-semantic-release on Travis CI
This guide expects you to have activated the repository on Travis CI. If this is not the case, please
refer to Travis documentation on how to do that.
1. Add python-semantic-release settings
See Configuration for details on how to configure Python Semantic Release. Make sure that at least you
have set version_variables before continuing.
2. Add environment variables
You will need to set up an environment variable in Travis. An easy way to do that is to go to the
settings page for your package and add it there. Make sure that the secret toggle is set correctly.
You need to set the GH_TOKEN environment variable with a personal access token for Github. It will need
either repo or public_repo scope depending on whether the repository is private or public.
More information on how to set environment variables can be found on Travis documentation on environment
variables.
3. Add travis configuration
The following should be added to your .travis.yml file.
after_success:
- git config --global user.name "semantic-release (via TravisCI)"
- git config --global user.email "semantic-release@travis"
- pip install python-semantic-release
- semantic-release version && semantic-release publish
The first line tells Travis that we want to run the listed tasks after a successful build. The two first
lines in after_success will configure git so that python-semantic-release will be able to commit on
Travis. The third installs the latest version of python-semantic-release. The last will run the publish
command, which will publish a new version if the changes indicate that one is due.
4. Push some changes
You are now ready to release automatically on Travis CI on every change to your master branch.
Happy coding!
GitHub Actions
There are two official GitHub Actions for Python Semantic Release:
1.
python-semantic-release/python-semantic-release@TAG
This is the main action that runs the version CLI command. It is used to (1) determine the next
version number, (2) stamp the version number, (3) run the build command, (4) build the
changelog, (5) commit the changes, (6) tag the commit, (7) publish the commit & tag and lastly
(8) create a GitHub release. For more information review the version command documentation and
see below for the Action configuration options.
2.
python-semantic-release/publish-action@TAG
This action is used to execute the publish CLI command. It is used to upload files, such as
distribution artifacts and other assets, to a GitHub release.
NOTE:
These GitHub Actions are only simplified wrappers around the python-semantic-release CLI. Ultimately,
they download and install the published package from PyPI so if you find that you are trying to do
something more advanced or less common, you may need to install and use the CLI directly.
Python Semantic Release Action
The official Python Semantic Release GitHub Action is a GitHub Docker Action, which means at the
beginning of the job it will build a Docker image that contains the Python Semantic Release package and
its dependencies. It will then run the job step inside the Docker Container. This is done to ensure that
the environment is consistent across all GitHub Runners regardless of platform. With this choice, comes
some limitations of non-configurable options like a pre-defined python version, lack of installed build
tools, and an inability to utilize caching.
The primary benefit of using the GitHub Action is that it is easy to set up and use for most projects. We
handle a lot of the git configuration under the hood, so you don't have to handle it yourself. There are
a plenty of customization options available which are detailed individually below.
Most importantly your project's configuration file will be used as normal, as your project will be
mounted into the container for the action to use.
SEE ALSO:
action.yml: the code definition of the action
Inputs
GitHub Action inputs are used for select configuration and provide the necessary information to execute
the action. The inputs are passed to the action using the with keyword in the workflow file. Many inputs
will mirror the command line options available in the version command. This section outlines each
supported input and its purpose.
----
build
Type: Literal["true", "false"]
Override whether the action should execute the build command or not. This option is equivalent to adding
the command line switch --skip-build (when false) to the version command. If set to true, no command line
switch is passed and the default behavior of the version is used.
Required: false
NOTE:
If not set or set to true, the default behavior is defined by the version command and any user
configurations.
SEE ALSO:
• --skip-build option for the version command.
----
build_metadata
Type: string
Explicitly set the build metadata of the version. This is equivalent to running the command:
semantic-release version --build-metadata <metadata>
Required: false
SEE ALSO:
• --build-metadata [VALUE] option for the version command
----
changelog
Type: Literal["true", "false"]
Override whether the action should generate a changelog or not. This option is equivalent to adding
either --changelog (on true) or --no-changelog (on false) to the version command.
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --changelog/--no-changelog options for the version command
----
commit
Type: Literal["true", "false"]
Override whether the action should commit any changes to the local repository. Changes include the
version stamps, changelog, and any other files that are modified and added to the index during the build
command. This option is equivalent to adding either --commit (on true) or --no-commit (on false) to the
version command.
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --commit/--no-commit options for the version command
----
directory
If the project is not at the root of the repository (like in monorepos), you can specify a sub-directory
to change into before running semantic-release.
Required: false
Default: .
----
force
Type: Literal["prerelease", "patch", "minor", "major"]
Force the next version to be a specific bump type. This is equivalent to running the command:
semantic-release version --<type>
# Ex: force a patch level version bump
semantic-release version --patch
Required: false
SEE ALSO:
• --major/--minor/--patch/--prerelease options for the version command
----
git_committer_email
The email of the account used to commit. If customized, it must be associated with the provided token.
Required: false
----
git_committer_name
The name of the account used to commit. If customized, it must be associated with the provided token.
Required: false
----
github_token
The GitHub Token is essential for access to your GitHub repository to allow the push of commits & tags as
well as to create a release. Not only do you need to provide the token as an input but you also need to
ensure that the token has the correct permissions.
The token should have the following permissions:
• id-token: write
• contents: write
Required: true
----
prerelease
Force the version to be a prerelease version when set to true. This is equivalent to running the command:
semantic-release version --as-prerelease
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --as-prerelease option for the version command
----
prerelease_token
Override any prerelease token in the configuration file with this value, if it is a pre-release. This
will override the matching release branch configuration's prerelease_token value. If you always want it
to be a prerelease then you must also set the prerelease input to true.
This option is equivalent to running the command:
semantic-release version --prerelease-token <token>
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --prerelease-token [VALUE] option for the version command
----
push
Type: Literal["true", "false"]
Override whether the action should push any commits or tags from the local repository to the remote
repository. This option is equivalent to adding either --push (on true) or --no-push (on false) to the
version command.
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --push/--no-push options for the version command
----
root_options
Additional options for the main semantic-release command, which will come before the version subcommand.
Example
- uses: python-semantic-release/python-semantic-release@v9.21.0
with:
root_options: "-vv --noop"
This configuration would cause the command to be semantic-release -vv --noop version, which would run
the version command verbosely but in no-operation mode.
Required: false
Default: -v
SEE ALSO:
• Options for the semantic-release command
----
ssh_public_signing_key
The public key associated with the private key used in signing a commit and tag.
Required: false
----
ssh_private_signing_key
The private key used to sign a commit and tag.
Required: false
----
tag
Type: Literal["true", "false"]
Override whether the action should create a version tag in the local repository. This option is
equivalent to adding either --tag (on true) or --no-tag (on false) to the version command.
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --tag/--no-tag options for the version command
----
vcs_release
Type: Literal["true", "false"]
Override whether the action should create a release on the VCS. This option is equivalent to adding
either --vcs-release (on true) or --no-vcs-release (on false) to the version command.
Required: false
NOTE:
If not set, the default behavior is defined by the version command and any user configurations.
SEE ALSO:
• --vcs-release/--no-vcs-release options for the version command
----
Outputs
The Python Semantic Release Action also provides outputs that can be used in subsequent steps of the
workflow. These outputs are used to provide information about the release and any actions that were
taken.
----
is_prerelease
Type: Literal["true", "false"]
A boolean value indicating whether the released version is a prerelease.
----
released
Type: Literal["true", "false"]
A boolean value indicating whether a release was made.
----
version
Type: string
The newly released SemVer version string if one was made, otherwise the current version.
Example: 1.2.3
----
tag
Type: string
The Git tag corresponding to the version output but in the tag format dictated by your configuration.
Example: v1.2.3
----
Python Semantic Release Publish Action
The official Python Semantic Release Publish Action is a GitHub Docker Action, which means at the
beginning of the job it will build a Docker image that contains the Python Semantic Release package and
its dependencies. It will then run the job step inside the Docker Container. This is done to ensure that
the environment is consistent across all GitHub Runners regardless of platform. With this choice, comes
some limitations of non-configurable options like a pre-defined python version, lack of additional 3rd
party tools, and an inability to utilize caching.
The primary benefit of using the GitHub Action is that it is easy to set up and use for most projects. We
handle some additional configuration under the hood, so you don't have to handle it yourself. We do
however provide a few customization options which are detailed individually below.
Most importantly your project's configuration file will be used as normal, as your project will be
mounted into the container for the action to use.
If you have issues with the action, please open an issue on the python-semantic-release/publish-action
repository.
SEE ALSO:
• action.yml: the code definition for the publish action
Inputs
GitHub Action inputs are used for select configuration and provide the necessary information to execute
the action. The inputs are passed to the action using the with keyword in the workflow file. Many inputs
will mirror the command line options available in the publish command and others will be specific to
adjustment of the action environment. This section outlines each supported input and its purpose.
----
directory
If the project is not at the root of the repository (like in monorepos), you can specify a sub-directory
to change into before running semantic-release.
Required: false
Default: .
----
github_token
The GitHub Token is essential for access to your GitHub repository to allow the publish of assets to a
release. Not only do you need to provide the token as an input but you also need to ensure that the token
has the correct permissions.
The token should have the following permissions:
• contents: write: Required for modifying a GitHub Release
Required: true
----
root_options
Additional options for the main semantic-release command, which will come before the publish subcommand.
Example
- uses: python-semantic-release/publish-action@v9.21.0
with:
root_options: "-vv --noop"
This configuration would cause the command to be semantic-release -vv --noop publish, which would run
the publish command verbosely but in no-operation mode.
Required: false
Default: -v
SEE ALSO:
• Options for the semantic-release command
----
tag
Type: string
The tag corresponding to the GitHub Release that the artifacts should be published to. This option is
equivalent to running the command:
semantic-release publish --tag <tag>
Python Semantic Release will automatically determine the latest release if no --tag option is provided.
Required: false
SEE ALSO:
• --tag option for the publish command
----
Outputs
There are no outputs provided by the Python Semantic Release Publish Action at this time.
NOTE:
If you would like outputs to be provided by this action, please open an issue on the ‐
python-semantic-release/publish-action repository.
----
Examples
Common Workflow Example
The following is a simple common workflow example that uses both the Python Semantic Release Action and
the Python Semantic Release Publish Action. This workflow will run on every push to the main branch and
will create a new release upon a successful version determination. If a version is released, the workflow
will then publish the package to PyPI and upload the package to the GitHub Release Assets as well.
name: Continuous Delivery
on:
push:
branches:
- main
jobs:
release:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-release-${{ github.ref_name }}
cancel-in-progress: false
permissions:
id-token: write
contents: write
steps:
# Note: We checkout the repository at the branch that triggered the workflow
# with the entire history to ensure to match PSR's release branch detection
# and history evaluation.
# However, we forcefully reset the branch to the workflow sha because it is
# possible that the branch was updated while the workflow was running. This
# prevents accidentally releasing un-evaluated changes.
- name: Setup | Checkout Repository on Release Branch
uses: actions/checkout@v4
with:
ref: ${{ github.ref_name }}
fetch-depth: 0
- name: Setup | Force release branch to be at workflow sha
run: |
git reset --hard ${{ github.sha }}
- name: Evaluate | Verify upstream has NOT changed
# Last chance to abort before causing an error as another PR/push was applied to
# the upstream branch while this workflow was running. This is important
# because we are committing a version change (--commit). You may omit this step
# if you have 'commit: false' in your configuration.
#
# You may consider moving this to a repo script and call it from this step instead
# of writing it in-line.
shell: bash
run: |
set +o pipefail
UPSTREAM_BRANCH_NAME="$(git status -sb | head -n 1 | cut -d' ' -f2 | grep -E '\.{3}' | cut -d'.' -f4)"
printf '%s\n' "Upstream branch name: $UPSTREAM_BRANCH_NAME"
set -o pipefail
if [ -z "$UPSTREAM_BRANCH_NAME" ]; then
printf >&2 '%s\n' "::error::Unable to determine upstream branch name!"
exit 1
fi
git fetch "${UPSTREAM_BRANCH_NAME%%/*}"
if ! UPSTREAM_SHA="$(git rev-parse "$UPSTREAM_BRANCH_NAME")"; then
printf >&2 '%s\n' "::error::Unable to determine upstream branch sha!"
exit 1
fi
HEAD_SHA="$(git rev-parse HEAD)"
if [ "$HEAD_SHA" != "$UPSTREAM_SHA" ]; then
printf >&2 '%s\n' "[HEAD SHA] $HEAD_SHA != $UPSTREAM_SHA [UPSTREAM SHA]"
printf >&2 '%s\n' "::error::Upstream has changed, aborting release..."
exit 1
fi
printf '%s\n' "Verified upstream branch has not changed, continuing with release..."
- name: Action | Semantic Version Release
id: release
# Adjust tag with desired version if applicable.
uses: python-semantic-release/python-semantic-release@v9.21.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
git_committer_name: "github-actions"
git_committer_email: "actions@users.noreply.github.com"
- name: Publish | Upload package to PyPI
uses: pypa/gh-action-pypi-publish@v1
if: steps.release.outputs.released == 'true'
- name: Publish | Upload to GitHub Release Assets
uses: python-semantic-release/publish-action@v9.21.0
if: steps.release.outputs.released == 'true'
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
tag: ${{ steps.release.outputs.tag }}
IMPORTANT:
The concurrency directive is used on the job to prevent race conditions of more than one release job
in the case if there are multiple pushes to main in a short period of time.
Secondly the Evaluate | Verify upstream has NOT changed step is used to ensure that the upstream
branch has not changed while the workflow was running. This is important because we are committing a
version change (commit: true) and there might be a push collision that would cause undesired behavior.
Review Issue #1201 for more detailed information.
WARNING:
You must set fetch-depth to 0 when using actions/checkout@v4, since Python Semantic Release needs
access to the full history to build a changelog and at least the latest tags to determine the next
version.
WARNING:
The GITHUB_TOKEN secret is automatically configured by GitHub, with the same permissions role as the
user who triggered the workflow run. This causes a problem if your default branch is protected to
specific users.
You can work around this by storing an administrator's Personal Access Token as a separate secret and
using that instead of GITHUB_TOKEN. In this case, you will also need to pass the new token to
actions/checkout (as the token input) in order to gain push access.
Version Overrides Example
In the case where you want to provide multiple command line options to the version command, you provide
them through the with directive in the workflow file. In this example, we want to force a patch version
bump, not produce a changelog, and provide specialized build metadata. As a regular CLI command, this
would look like:
semantic-release version --patch --no-changelog --build-metadata abc123
The equivalent GitHub Action configuration would be:
# snippet
- name: Action | Semantic Version Release
# Adjust tag with desired version if applicable.
uses: python-semantic-release/python-semantic-release@v9.21.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
force: patch
changelog: false
build_metadata: abc123
Actions with Monorepos
While python-semantic-release does NOT have full monorepo support, if you have multiple projects stored
within a single repository (or your project is not at the root of the repository), you can pass the
directory input to the action to change directory before semantic-release execution.
For multiple packages, you would need to run the action multiple times, to release each project. The
following example demonstrates how to release two projects in a monorepo.
The directory input directive is also available for the Python Semantic Release Publish Action.
- name: Release Project 1
uses: python-semantic-release/python-semantic-release@v9.21.0
with:
directory: ./project1
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Release Project 2
uses: python-semantic-release/python-semantic-release@v9.21.0
with:
directory: ./project2
github_token: ${{ secrets.GITHUB_TOKEN }}
Publish with cronjobs
This is for you if for some reason you cannot publish from your CI or you would like releases to drop at
a certain interval. Before you start, answer this: Are you sure you do not want a CI to release for you?
(high version numbers are not a bad thing).
The guide below is for setting up scheduled publishing on a server. It requires that the user that runs
the cronjob has push access to the repository and upload access to an artifact repository.
1. Create a virtualenv:
virtualenv semantic_release -p `which python3`
2. Install python-semantic-release:
pip install python-semantic-release
3. Clone the repositories you want to have scheduled publishing. 3. Put the following in publish:
VENV=semantic_release/bin
$VENV/pip install -U pip python-semantic-release > /dev/null
publish() {
cd $1
git stash -u # ensures that there is no untracked files in the directory
git fetch && git reset --hard origin/master
$VENV/semantic-release version && $VENV/semantic-release publish
cd ..
}
publish <package1>
publish <package2>
4. Add cronjob:
/bin/bash -c "cd <path> && source semantic_release/bin/activate && ./publish 2>&1 >> releases.log"
Troubleshooting
• Check your configuration file for Configuration
• Check your Git tags match your tag_format; tags using other formats are ignored during calculation of
the next version.
Increasing Verbosity
If you are having trouble with Python Semantic Release or would like to see additional information about
the actions that it is taking, you can use the top-level -v/--verbose option. This can be supplied
multiple times to increase the logging verbosity of the semantic-release command or any of its
subcommands during their execution. You can supply this as many times as you like, but supplying more
than twice has no effect.
Supply -v/--verbose once for INFO output, and twice for DEBUG.
For example:
semantic-release -vv version --print
NOTE:
The -v/--verbose option must be supplied to the top-level semantic-release command, before the name of
any sub-command.
WARNING:
The volume of logs when using DEBUG verbosity may be significantly increased, compared to INFO or the
default WARNING, and as a result executing commands with semantic-release may be significantly slower
than when using DEBUG.
NOTE:
The provided GitHub action sets the verbosity level to INFO by default.
Contributing
If you want to contribute that is awesome. Remember to be nice to others in issues and reviews.
Please remember to write tests for the cool things you create or fix.
Unsure about something? No worries, open an issue.
Commit messages
Since python-semantic-release is released with python-semantic-release we need the commit messages to
adhere to the Conventional Commits Specification. Although scopes are optional, scopes are expected
where applicable. Changes should be committed separately with the commit type they represent, do not
combine them all into one commit.
If you are unsure how to describe the change correctly just try and ask about it in your pr. If we think
it should be something else or there is a pull-request without tags we will help out in adding or
changing them.
Releases
This package is released by python-semantic-release on each master build, thus if there are changes that
should result in a new release it will happen if the build is green.
Development
Install this module and the development dependencies
pip install -e .[dev,mypy,test]
And if you'd like to build the documentation locally
pip install -e .[docs]
sphinx-autobuild --open-browser docs docs/_build/html
Testing
To test your modifications locally:
# Run type-checking, all tests across all supported Python versions
tox
# Run all tests for your current installed Python version (with full error output)
pytest -vv --comprehensive
# Run unit tests for your current installed Python version
pytest
# or
pytest -vv -m unit
# Run end-to-end tests for your current installed Python version (with full error output)
pytest -vv -m e2e [--comprehensive]
The --comprehensive flag is optional and will run all the variations of tests and it does take
significantly longer to run.
Building
This project is designed to be versioned and built by itself using the tool.semantic_release
configuration in pyproject.toml. The setting tool.semantic_release.build_command defines the command to
run to build the package.
The following is a copy of the build_command setting which can be run manually to build the package
locally:
pip install -e .[build]
python -m build .
Migrating from Python Semantic Release v7
Python Semantic Release 8.0.0 introduced a number of breaking changes. 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
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.
Python Semantic Release GitHub Action
GitHub Action no longer publishes artifacts to PyPI or GitHub Releases
Python Semantic Release no longer uploads distributions to PyPI - see Repurposing of version and publish
commands. If you are 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.
This means the following workflows perform the same actions, and if you are using the former, you will
need to modify your workflow to include the steps in the latter.
This workflow is written to use Python Semantic Release v7.33.5:
---
name: Semantic Release
on:
push:
branches:
- main
jobs:
release:
runs-on: ubuntu-latest
concurrency: release
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
# This action uses Python Semantic Release v7
- name: Python Semantic Release
uses: python-semantic-release/python-semantic-release@v7.33.5
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
repository_username: __token__
repository_password: ${{ secrets.PYPI_TOKEN }}
The following workflow achieves the same result using Python Semantic Release v8, the ‐
upload-to-gh-release GitHub Action, and the pypa/gh-action-pypi-publish GitHub Action:
---
name: Semantic Release
on:
push:
branches:
- main
jobs:
release:
runs-on: ubuntu-latest
concurrency: release
permissions:
id-token: write
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
# This action uses Python Semantic Release v8
- name: Python Semantic Release
id: release
uses: python-semantic-release/python-semantic-release@v8.7.0
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Publish package distributions to PyPI
uses: pypa/gh-action-pypi-publish@v1
# NOTE: DO NOT wrap the conditional in ${{ }} as it will always evaluate to true.
# See https://github.com/actions/runner/issues/1173
if: steps.release.outputs.released == 'true'
- name: Publish package distributions to GitHub Releases
uses: python-semantic-release/upload-to-gh-release@v8.7.0
if: steps.release.outputs.released == 'true'
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
Removal of pypi_token, repository_username and repository_password inputs
Since the library no longer supports publishing to PyPI, the pypi_token, repository_username and
repository_password inputs of the GitHub action have all been removed. See the above section for how to
publish to PyPI using the official GitHub Action from the Python Packaging Authority (PyPA).
Rename additional_options to root_options
Because the purposes of the semantic-release version and semantic-release publish commands have changed,
the GitHub action now performs both commands in sequence. For this reason, and because the usage of the
CLI has changed, additional_options has been renamed to root_options to reflect the fact that the options
are for the main semantic-release command group.
Commands
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 artifacts to artefact repositories, creating releases in remote
version control systems, and writing changelogs.
In Python Semantic Release <8.0.0, the publish command was a one-stop-shop for performing every piece of
automation provided. This has been changed - the version 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 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 artifacts to package indexes such as PyPI, and it's recommended to use twine directly via the
command-line. From the twine documentation:
Twine is a command-line tool for interacting with PyPI securely over HTTPS.
As a result Python Semantic Release no longer depends on twine internals.
The publish command now handles publishing software artifacts to releases in the remote version control
system.
To achieve a similar flow of logic such as
1. Determine the next version
2. Write this version to the configured metadata locations
3. Write the changelog
4. Push the changes to the metadata and changelog to the remote repository
5. Create a release in the remote version control system
6. Build a wheel
7. Publish the wheel to PyPI
8. Publish the distribution artifacts to the release in the remote VCS
You should run:
semantic-release version
twine upload dist/* # or whichever path your distributions are placed in
semantic-release publish
With steps 1-6 being handled by the semantic-release version command, step 7 being left to the developer
to handle, and lastly step 8 to be handled by the semantic-release publish command.
Removal of -D/--define command-line option
It is no longer possible to override arbitrary configuration values using the -D/ --define option. You
should provide the appropriate values via a configuration file using -c/--config [FILE] or via the
available command-line options.
This simplifies the command-line option parsing significantly and is less error-prone, which has resulted
in previous issues (e.g. #600) with overrides on the command-line. Some of the configuration values
expected by Python Semantic Release use complex data types such as lists or nested structures, which
would be tedious and error-prone to specify using just command-line options.
Removal of CI verifications
Prior to v8, Python Semantic Release would perform some prerequisite verification of environment
variables before performing any version changes using the publish command. It's not feasible for Python
Semantic Release to verify any possible CI environment fully, and these checks were only triggered if
certain environment variables were set - they wouldn't fail locally.
These checks previously raised :py:class:semantic_release.CiVerificationError, and were the only place in
which this custom exception was used. Therefore, this exception has also been removed from Python
Semantic Release in v8.
If you were relying on this functionality, it's recommended that you add the following shell commands
before invoking semantic-release to verify your environment:
NOTE:
In the following, $RELEASE_BRANCH refers to the git branch against which you run your releases using
Python Semantic Release. You will need to ensure it is set properly (e.g. via export
RELEASE_BRANCH=main and/or replace the variable with the branch name you want to verify the CI
environment for.
Travis
Condition: environment variable TRAVIS=true
Replacement:
if ! [[
$TRAVIS_BRANCH == $RELEASE_BRANCH && \
$TRAVIS_PULL_REQUEST == 'false'
]]; then
exit 1
fi
Semaphore
Condition: environment variable SEMAPHORE=true
Replacement:
if ! [[
$BRANCH_NAME == $RELEASE_BRANCH && \
$SEMAPHORE_THREAD_RESULT != 'failed' && \
-n $PULL_REQUEST_NUMBER
]]; then
exit 1
fi
Frigg
Condition: environment variable FRIGG=true
Replacement:
if ! [[
$FRIGG_BUILD_BRANCH == $RELEASE_BRANCH && \
-n $FRIGG_PULL_REQUEST
]]; then
exit 1
fi
Circle CI
Condition: environment variable CIRCLECI=true
Replacement:
if ! [[
$CIRCLE_BRANCH == $RELEASE_BRANCH && \
-n $CI_PULL_REQUEST
]]; then
exit 1
fi
GitLab CI
Condition: environment variable GITLAB_CI=true
Replacement:
if ! [[ $CI_COMMIT_REF_NAME == $RELEASE_BRANCH ]]; then
exit 1
fi
Condition: environment variable BITBUCKET_BUILD_NUMBER is set
Replacement:
if ! [[
$BITBUCKET_BRANCH == $RELEASE_BRANCH && \
-n $BITBUCKET_PR_ID
]]; then
exit 1
fi
Jenkins
Condition: environment variable JENKINS_URL is set
Replacement:
if [[ -z $BRANCH_NAME ]]; then
BRANCH_NAME=$BRANCH_NAME
elif [[ -z $GIT_BRANCH ]]; then
BRANCH_NAME=$GIT_BRANCH
fi
if ! [[
$BRANCH_NAME == $RELEASE_BRANCH && \
-n $CHANGE_ID
]]; then
exit 1
fi
Removal of Build Status Checking
Prior to v8, Python Semantic Release contained a configuration option, check_build_status, which would
attempt to prevent a release being made if it was possible to identify that a corresponding build
pipeline was failing. For similar reasons to those motivating the removal of CI Checks, this feature has
also been removed.
If you are leveraging this feature in Python Semantic Release v7, the following bash commands will
replace the functionality, and you can add these to your pipeline. You will need to install jq and curl
to run these commands; they can be easily installed through your system's package manager, for example on
Ubuntu:
sudo apt update && sudo apt upgrade
sudo apt install -y curl jq
On Windows, you can refer to the installation guide for jq, and if curl is not already installed, you can
download it from the curl website
GitHub
export RESP="$(
curl \
-H "Authorization: token $GITHUB_TOKEN" \
-fSsL https://$GITHUB_API_DOMAIN/repos/$REPO_OWNER/$REPO_NAME/commits/$(git rev-parse HEAD)/status || exit 1
)"
if [ $(jq -r '.state' <<< "$RESP") != "success" ]; then
echo "Build status is not success" >&2
exit 1
fi
Note that $GITHUB_API_DOMAIN is typically api.github.com unless you are using GitHub Enterprise with a
custom domain name.
Gitea
export RESP="$(
curl \
-H "Authorization: token $GITEA_TOKEN" \
-fSsL https://$GITEA_DOMAIN/repos/$REPO_OWNER/$REPO_NAME/statuses/$(git rev-parse HEAD) || exit 1
)"
if [ $(jq -r '.state' <<< "$RESP") != "success" ]; then
echo "Build status is not success" >&2
exit 1
fi
Gitlab
export RESP="$(
curl \
-H "Authorization: token $GITLAB_TOKEN" \
-fSsL https://$GITLAB_DOMAIN/api/v4/projects/$PROJECT_ID/repository/commits/$(git rev-parse HEAD)/statuses
)"
for line in $(jq -r '.[] | [.name, .status, .allow_failure] | join("|")' <<<"$RESP"); do
IFS="|" read -r job_name job_status allow_failure <<<"$line"
if [ "$job_status" == "pending" ]; then
echo "job $job_name is pending" >&2
exit 1
elif [ "$job_status" == "failed" ] && [ ! "$allow_failure" == "true" ]; then
echo "job $job_name failed" >&2
exit 1
fi
done
Multibranch releases
Prior to v8, Python Semantic Release would perform git checkout to switch to your configured release
branch and determine if a release would need to be made. In v8 this has been changed - you must manually
check out the branch which you would like to release against, and if you would like to create releases
against this branch you must also ensure that it belongs to a release group.
changelog command
A new option, --post-to-release-tag [TAG] has been added. If you omit this argument on the command line
then the changelog rendering process, which is described in more detail at Custom Changelogs, will be
triggered, but the new changelog will not be posted to any release. If you use this new command-line
option, it should be set to a tag within the remote which has a corresponding release. For example, to
update the changelog and post it to the release corresponding to the tag v1.1.4, you should run:
semantic-release changelog --post-to-release-tag v1.1.4
Changelog customization
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
customization has grown significantly; it now uses templates in order to fully open up customizing the
changelog's appearance.
Configuration
The configuration structure has been completely reworked, so you should read Configuration carefully
during the process of upgrading to v8+. However, some common pitfalls and potential sources of confusion
are summarized here.
setup.cfg is no longer supported
Python Semantic Release no longer supports configuration via setup.cfg. This is because the Python
ecosystem is centering around pyproject.toml as universal tool and project configuration file, and TOML
allows expressions via configuration, such as the mechanism for declaring configuration via environment
variables, which introduce much greater complexity to support in the otherwise equivalent ini-format
configuration.
You can use semantic-release generate-config to generate new-format configuration that can be added to
pyproject.toml, and adjust the default settings according to your needs.
WARNING:
If you don't already have a pyproject.toml configuration file, pip can 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 --config
option to reference this alternative configuration file.
More detail about this issue can be found in this pip issue.
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 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
commit_parser_options, and if you need to parse multiple commit styles for a single project it's
recommended that you create a parser following Custom Parsers that is tailored to the specific needs of
your project.
version_variable
This option has been renamed to version_variables as it refers to a list of variables which can be
updated.
version_pattern
This option has been removed. It's recommended to use an alternative tool to perform substitution using
arbitrary regular expressions, such as sed. You can always use Python Semantic Release to identify the
next version to be created for a project and store this in an environment variable like so:
export VERSION=$(semantic-release version --print)
version_toml
This option will no longer accept a string or comma-separated string of version locations to be updated
in TOML files. Instead, you must supply a List[str]. For existing configurations using a single location
in this option, you can simply wrap the value in []:
# Python Semantic Release v7 configuration
[tool.semantic_release]
version_toml = "pyproject.toml:tool.poetry.version"
# Python Semantic Release v8 configuration
[tool.semantic_release]
version_toml = ["pyproject.toml:tool.poetry.version"]
tag_format
This option has the same effect as it did in Python Semantic Release prior to v8, but Python Semantic
Release will now verify that it has a {version} format key and raise an error if this is not the case.
upload_to_release
This option has been renamed to upload_to_vcs_release.
Custom Commit Parsers
Previously, a custom commit parser had to satisfy the following criteria:
• It should be import-able from the virtual environment where the semantic-release is run
• It should be a function which accepts the commit message as its only argument and returns a
semantic_release.history.parser_helpers.ParsedCommit if the commit is parsed successfully, or raise
a semantic_release.UnknownCommitMessageStyleError if parsing is unsuccessful.
It is still possible to implement custom commit parsers, but the interface for doing so has been modified
with stronger support for Python type annotations and broader input provided to the parser to enable
capturing more information from each commit, such as the commit's date and author, if desired. A full
guide to implementing a custom commit parser can be found at Custom Parsers.
src
semantic_release package
Python Semantic Release
semantic_release.setup_hook(argv: list[str]) -> None
A hook to be used in setup.py to enable python setup.py publish.
Parameters
argv -- sys.argv
Subpackages
semantic_release.changelog package
Submodules
semantic_release.changelog.context module
class semantic_release.changelog.context.ChangelogContext(repo_name: 'str', repo_owner: 'str', hvcs_type:
'str', history: 'ReleaseHistory', changelog_mode: "Literal['update', 'init']", prev_changelog_file:
'str', changelog_insertion_flag: 'str', mask_initial_release: 'bool', filters: 'tuple[Callable[..., Any],
...]' = ())
Bases: object
bind_to_environment(env: Environment) -> Environment
changelog_insertion_flag: str
changelog_mode: Literal['update', 'init']
filters: tuple[Callable[..., Any], ...] = ()
history: ReleaseHistory
hvcs_type: str
mask_initial_release: bool
prev_changelog_file: str
repo_name: str
repo_owner: str
class semantic_release.changelog.context.ChangelogMode(value, names=<not given>, *values, module=None,
qualname=None, type=None, start=1, boundary=None)
Bases: Enum
INIT = 'init'
UPDATE = 'update'
class semantic_release.changelog.context.ReleaseNotesContext(repo_name: 'str', repo_owner: 'str',
hvcs_type: 'str', version: 'Version', release: 'Release', mask_initial_release: 'bool', license_name:
'str', filters: 'tuple[Callable[..., Any], ...]' = ())
Bases: object
bind_to_environment(env: Environment) -> Environment
filters: tuple[Callable[..., Any], ...] = ()
hvcs_type: str
license_name: str
mask_initial_release: bool
release: Release
repo_name: str
repo_owner: str
version: Version
semantic_release.changelog.context.autofit_text_width(text: str, maxwidth: int = 100, indent_size: int =
0) -> str
Format the description text to fit within a specified width
semantic_release.changelog.context.convert_md_to_rst(md_content: str) -> str
semantic_release.changelog.context.create_pypi_url(package_name: str, version: str = '') -> str
semantic_release.changelog.context.make_changelog_context(hvcs_client: HvcsBase, release_history:
ReleaseHistory, mode: ChangelogMode, prev_changelog_file: Path, insertion_flag: str,
mask_initial_release: bool) -> ChangelogContext
semantic_release.changelog.context.read_file(filepath: str) -> str
semantic_release.changelog.release_history module
class semantic_release.changelog.release_history.Release
Bases: TypedDict
committer: Actor
elements: dict[str, list[ParseResult]]
tagged_date: datetime
tagger: Actor
version: Version
class semantic_release.changelog.release_history.ReleaseHistory(unreleased: dict[str, list[ParseResult]],
released: dict[Version, Release])
Bases: object
classmethod from_git_history(repo: Repo, translator: VersionTranslator, commit_parser:
CommitParser[ParseResult, ParserOptions], exclude_commit_patterns: Iterable[Pattern[str]] = ()) ->
ReleaseHistory
release(version: Version, tagger: Actor, committer: Actor, tagged_date: datetime) ->
ReleaseHistory
semantic_release.changelog.template module
class semantic_release.changelog.template.ComplexDirectorySandboxedEnvironment(*args: Any, **kwargs: Any)
Bases: SandboxedEnvironment
join_path(template: str, parent: str) -> str
Add support for complex directory structures in the template directory.
This method overrides the default functionality of the SandboxedEnvironment where all
'include' keywords expect to be in the same directory as the calling template, however this
is unintuitive when using a complex directory structure.
This override simulates the changing of directories when you include the template from a
child directory. When the child then includes a template, it will make the path relative to
the child directory rather than the top level template directory.
semantic_release.changelog.template.environment(template_dir: Path | str = '.', block_start_string: str =
'{%', block_end_string: str = '%}', variable_start_string: str = '{{', variable_end_string: str = '}}',
comment_start_string: str = '{#', comment_end_string: str = '#}', line_statement_prefix: str | None =
None, line_comment_prefix: str | None = None, trim_blocks: bool = False, lstrip_blocks: bool = False,
newline_sequence: Literal['\n', '\r', '\r\n'] = '\n', keep_trailing_newline: bool = False, extensions:
Iterable[str] = (), autoescape: bool | str = True) -> SandboxedEnvironment
Create a jinja2.sandbox.SandboxedEnvironment with certain parameter resrictions.
For example the Loader is fixed to FileSystemLoader, although the searchpath is configurable.
autoescape can be a string in which case it should follow the convention module:attr, in this
instance it will be dynamically imported. See ‐
https://jinja.palletsprojects.com/en/3.1.x/api/#jinja2.Environment for full parameter descriptions
semantic_release.changelog.template.recursive_render(template_dir: Path, environment: Environment,
_root_dir: str | os.PathLike[str] = '.') -> list[str]
semantic_release.cli package
Subpackages
semantic_release.cli.commands package
Submodules
semantic_release.cli.commands.changelog module
semantic_release.cli.commands.changelog.get_license_name_for_release(tag_name: str, project_root: Path)
-> str
semantic_release.cli.commands.changelog.post_release_notes(release_tag: str, release_notes: str,
prerelease: bool, hvcs_client: RemoteHvcsBase, noop: bool = False) -> None
semantic_release.cli.commands.generate_config module
semantic_release.cli.commands.main module
class semantic_release.cli.commands.main.Cli(name: str | None = None, invoke_without_command: bool =
False, no_args_is_help: bool | None = None, subcommand_metavar: str | None = None, chain: bool = False,
result_callback: Callable[[...], Any] | None = None, **attrs: Any)
Bases: MultiCommand
Root MultiCommand for the semantic-release CLI
class SubCmds(value, names=<not given>, *values, module=None, qualname=None, type=None, start=1,
boundary=None)
Bases: Enum
Subcommand import definitions
CHANGELOG = 'semantic_release.cli.commands.changelog'
GENERATE_CONFIG = 'semantic_release.cli.commands.generate_config'
PUBLISH = 'semantic_release.cli.commands.publish'
VERSION = 'semantic_release.cli.commands.version'
get_command(_ctx: Context, name: str) -> Command | None
Given a context and a command name, this returns a Command object if it exists or returns
None.
list_commands(_ctx: Context) -> list[str]
Returns a list of subcommand names in the order they should appear.
semantic_release.cli.commands.publish module
semantic_release.cli.commands.publish.publish_distributions(tag: str, hvcs_client: RemoteHvcsBase,
dist_glob_patterns: tuple[str, ...], noop: bool = False) -> None
semantic_release.cli.commands.version module
semantic_release.cli.commands.version.apply_version_to_source_files(repo_dir: Path, version_declarations:
Sequence[IVersionReplacer], version: Version, noop: bool = False) -> list[str]
semantic_release.cli.commands.version.build_distributions(build_command: str | None, build_command_env:
Mapping[str, str] | None = None, noop: bool = False) -> None
Run the build command to build the distributions.
Parameters
• build_command -- The build command to run.
• build_command_env -- The environment variables to use when running the build command.
• noop -- Whether or not to run the build command.
Raises BuildDistributionsError: if the build command fails
semantic_release.cli.commands.version.get_windows_env() -> Mapping[str, str | None]
semantic_release.cli.commands.version.is_forced_prerelease(as_prerelease: bool, forced_level_bump:
LevelBump | None, prerelease: bool) -> bool
Determine if this release is forced to have prerelease on/off. If force_prerelease is set then
yes. Otherwise if we are forcing a specific level bump without force_prerelease, it's False.
Otherwise (force_level is None) use the value of prerelease
semantic_release.cli.commands.version.is_windows() -> bool
semantic_release.cli.commands.version.last_released(repo_dir: Path, tag_format: str) -> tuple[Tag,
Version] | None
semantic_release.cli.commands.version.shell(cmd: str, *, env: Mapping[str, str] | None = None, check:
bool = True) -> subprocess.CompletedProcess
semantic_release.cli.commands.version.version_from_forced_level(repo_dir: Path, forced_level_bump:
LevelBump, translator: VersionTranslator) -> Version
Submodules
semantic_release.cli.changelog_writer module
semantic_release.cli.changelog_writer.apply_user_changelog_template_directory(template_dir: Path,
environment: Environment, destination_dir: Path, noop: bool = False) -> list[str]
semantic_release.cli.changelog_writer.generate_release_notes(hvcs_client: HvcsBase, release: Release,
template_dir: Path, history: ReleaseHistory, style: str, mask_initial_release: bool, license_name: str =
'') -> str
semantic_release.cli.changelog_writer.get_default_tpl_dir(style: str, sub_dir: str | None = None) -> Path
semantic_release.cli.changelog_writer.render_default_changelog_file(output_format: ChangelogOutputFormat,
changelog_context: ChangelogContext, changelog_style: str) -> str
semantic_release.cli.changelog_writer.render_release_notes(release_notes_template_file: str,
template_env: Environment) -> str
semantic_release.cli.changelog_writer.write_changelog_files(runtime_ctx: RuntimeContext, release_history:
ReleaseHistory, hvcs_client: HvcsBase, noop: bool = False) -> list[str]
semantic_release.cli.changelog_writer.write_default_changelog(changelog_file: Path, destination_dir:
Path, output_format: ChangelogOutputFormat, changelog_context: ChangelogContext, changelog_style: str,
noop: bool = False) -> str
semantic_release.cli.cli_context module
class semantic_release.cli.cli_context.CliContextObj(ctx: click.Context, logger: logging.Logger,
global_opts: GlobalCommandLineOptions)
Bases: object
property raw_config: RawConfig
property runtime_ctx: RuntimeContext
Lazy load the runtime context. This is done to avoid configuration loading when the command
is not run. This is useful for commands like --help and --version
semantic_release.cli.config module
class semantic_release.cli.config.BranchConfig(*, match: str = '(main|master)', prerelease_token: str =
'rc', prerelease: bool = False)
Bases: BaseModel
match: str
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
prerelease: bool
prerelease_token: str
classmethod validate_match(match: str) -> str
class semantic_release.cli.config.ChangelogConfig(*, changelog_file: str = '', default_templates:
~semantic_release.cli.config.DefaultChangelogTemplatesConfig =
DefaultChangelogTemplatesConfig(changelog_file='CHANGELOG.md',
output_format=<ChangelogOutputFormat.MARKDOWN: 'md'>, mask_initial_release=False), environment:
~semantic_release.cli.config.ChangelogEnvironmentConfig =
ChangelogEnvironmentConfig(block_start_string='{%', block_end_string='%}', variable_start_string='{{',
variable_end_string='}}', comment_start_string='{#', comment_end_string='#}', line_statement_prefix=None,
line_comment_prefix=None, trim_blocks=False, lstrip_blocks=False, newline_sequence='\n',
keep_trailing_newline=False, extensions=(), autoescape=False), exclude_commit_patterns:
~typing.Tuple[str, ...] = (), mode: ~semantic_release.changelog.context.ChangelogMode =
ChangelogMode.INIT, insertion_flag: str = '', template_dir: str = 'templates')
Bases: BaseModel
changelog_file: str
Deprecated! Moved to 'default_templates.changelog_file'
classmethod changelog_file_deprecation_warning(val: str) -> str
default_templates: DefaultChangelogTemplatesConfig
environment: ChangelogEnvironmentConfig
exclude_commit_patterns: Tuple[str, ...]
insertion_flag: str
load_default_insertion_flag_on_missing() -> Self
mode: ChangelogMode
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
move_changelog_file() -> Self
template_dir: str
classmethod validate_match(patterns: Tuple[str, ...]) -> Tuple[str, ...]
class semantic_release.cli.config.ChangelogEnvironmentConfig(*, block_start_string: str = '{%',
block_end_string: str = '%}', variable_start_string: str = '{{', variable_end_string: str = '}}',
comment_start_string: str = '{#', comment_end_string: str = '#}', line_statement_prefix: str | None =
None, line_comment_prefix: str | None = None, trim_blocks: bool = False, lstrip_blocks: bool = False,
newline_sequence: Literal['\n', '\r', '\r\n'] = '\n', keep_trailing_newline: bool = False, extensions:
Tuple[str, ...] = (), autoescape: bool | str = False)
Bases: BaseModel
autoescape: bool | str
block_end_string: str
block_start_string: str
comment_end_string: str
comment_start_string: str
extensions: Tuple[str, ...]
keep_trailing_newline: bool
line_comment_prefix: str | None
line_statement_prefix: str | None
lstrip_blocks: bool
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
newline_sequence: Literal['\n', '\r', '\r\n']
trim_blocks: bool
variable_end_string: str
variable_start_string: str
class semantic_release.cli.config.ChangelogOutputFormat(value, names=<not given>, *values, module=None,
qualname=None, type=None, start=1, boundary=None)
Bases: str, Enum
Supported changelog output formats when using the default templates.
MARKDOWN = 'md'
NONE = ''
RESTRUCTURED_TEXT = 'rst'
class semantic_release.cli.config.DefaultChangelogTemplatesConfig(*, changelog_file: str =
'CHANGELOG.md', output_format: ChangelogOutputFormat = ChangelogOutputFormat.NONE, mask_initial_release:
bool = False)
Bases: BaseModel
changelog_file: str
interpret_output_format() -> Self
mask_initial_release: bool
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
output_format: ChangelogOutputFormat
class semantic_release.cli.config.EnvConfigVar(*, env: str, default: str | None = None, default_env: str
| None = None)
Bases: BaseModel
default: str | None
default_env: str | None
env: str
getvalue() -> str | None
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
class semantic_release.cli.config.GlobalCommandLineOptions(noop: bool = False, verbosity: int = 0,
config_file: str = 'pyproject.toml', strict: bool = False)
Bases: object
A dataclass to hold all the command line options that should be set in the RuntimeContext
config_file: str = 'pyproject.toml'
noop: bool = False
strict: bool = False
verbosity: int = 0
class semantic_release.cli.config.HvcsClient(value, names=<not given>, *values, module=None,
qualname=None, type=None, start=1, boundary=None)
Bases: str, Enum
BITBUCKET = 'bitbucket'
GITEA = 'gitea'
GITHUB = 'github'
GITLAB = 'gitlab'
class semantic_release.cli.config.PublishConfig(*, dist_glob_patterns: Tuple[str, ...] = ('dist/*',),
upload_to_vcs_release: bool = True)
Bases: BaseModel
dist_glob_patterns: Tuple[str, ...]
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
upload_to_vcs_release: bool
class semantic_release.cli.config.RawConfig(*, assets: ~typing.List[str] = [], branches:
~typing.Dict[str, ~semantic_release.cli.config.BranchConfig] = {'main':
BranchConfig(match='(main|master)', prerelease_token='rc', prerelease=False)}, build_command: str | None
= None, build_command_env: ~typing.List[str] = [], changelog:
~semantic_release.cli.config.ChangelogConfig = ChangelogConfig(changelog_file='',
default_templates=DefaultChangelogTemplatesConfig(changelog_file='CHANGELOG.md',
output_format=<ChangelogOutputFormat.MARKDOWN: 'md'>, mask_initial_release=False),
environment=ChangelogEnvironmentConfig(block_start_string='{%', block_end_string='%}',
variable_start_string='{{', variable_end_string='}}', comment_start_string='{#', comment_end_string='#}',
line_statement_prefix=None, line_comment_prefix=None, trim_blocks=False, lstrip_blocks=False,
newline_sequence='\n', keep_trailing_newline=False, extensions=(), autoescape=False),
exclude_commit_patterns=(), mode=<ChangelogMode.INIT: 'init'>, insertion_flag='<!-- version list -->',
template_dir='templates'), commit_author: ~semantic_release.cli.config.EnvConfigVar | str =
EnvConfigVar(env='GIT_COMMIT_AUTHOR', default='semantic-release <semantic-release>', default_env=None),
commit_message: str = '{version}\n\nAutomatically generated by python-semantic-release', commit_parser:
~typing.Annotated[str, ~annotated_types.MinLen(min_length=1)] = 'conventional', commit_parser_options:
~typing.Dict[str, ~typing.Any] = {}, logging_use_named_masks: bool = False, major_on_zero: bool = True,
allow_zero_version: bool = True, repo_dir: ~pathlib._local.Path = PosixPath('.'), remote:
~semantic_release.cli.config.RemoteConfig = RemoteConfig(name='origin', token=None, url=None,
type=<HvcsClient.GITHUB: 'github'>, domain=None, api_domain=None, ignore_token_for_push=False,
insecure=False), no_git_verify: bool = False, tag_format: str = 'v{version}', publish:
~semantic_release.cli.config.PublishConfig = PublishConfig(dist_glob_patterns=('dist/*', ),
upload_to_vcs_release=True), version_toml: ~typing.Tuple[str, ...] | None = None, version_variables:
~typing.Tuple[str, ...] | None = None)
Bases: BaseModel
allow_zero_version: bool
classmethod angular_commit_parser_deprecation_warning(val: str) -> str
assets: List[str]
branches: Dict[str, BranchConfig]
build_command: str | None
build_command_env: List[str]
changelog: ChangelogConfig
commit_author: MaybeFromEnv
commit_message: str
commit_parser: NonEmptyString
commit_parser_options: Dict[str, Any]
classmethod convert_str_to_path(value: Any) -> Path
logging_use_named_masks: bool
major_on_zero: bool
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
no_git_verify: bool
publish: PublishConfig
remote: RemoteConfig
classmethod remove_whitespace(val: list[str]) -> list[str]
repo_dir: Annotated[Path, Field(validate_default=True)]
set_default_opts() -> Self
classmethod tag_commit_parser_deprecation_warning(val: str) -> str
tag_format: str
classmethod verify_git_repo_dir(dir_path: Path) -> Path
version_toml: Tuple[str, ...] | None
version_variables: Tuple[str, ...] | None
class semantic_release.cli.config.RemoteConfig(*, name: str = 'origin', token: str | None = None, url:
str | None = None, type: HvcsClient = HvcsClient.GITHUB, domain: str | None = None, api_domain: str |
None = None, ignore_token_for_push: bool = False, insecure: bool = False)
Bases: BaseModel
api_domain: str | None
check_insecure_flag(url_str: str, field_name: str) -> None
check_url_scheme() -> Self
domain: str | None
ignore_token_for_push: bool
insecure: bool
model_config: ClassVar[ConfigDict] = {}
Configuration for the model, should be a dictionary conforming to
[ConfigDict][pydantic.config.ConfigDict].
name: str
classmethod resolve_env_vars(val: Any) -> str | None
set_default_token() -> Self
token: str | None
type: HvcsClient
url: str | None
class semantic_release.cli.config.RuntimeContext(project_metadata: 'dict[str, Any]', repo_dir: 'Path',
commit_parser: 'CommitParser[ParseResult, ParserOptions]', version_translator: 'VersionTranslator',
major_on_zero: 'bool', allow_zero_version: 'bool', prerelease: 'bool', no_git_verify: 'bool', assets:
'List[str]', commit_author: 'Actor', commit_message: 'str', changelog_excluded_commit_patterns:
'Tuple[Pattern[str], ...]', version_declarations: 'Tuple[IVersionReplacer, ...]', hvcs_client:
'hvcs.HvcsBase', changelog_insertion_flag: 'str', changelog_mask_initial_release: 'bool', changelog_mode:
'ChangelogMode', changelog_file: 'Path', changelog_style: 'str', changelog_output_format:
'ChangelogOutputFormat', ignore_token_for_push: 'bool', template_environment: 'Environment',
template_dir: 'Path', build_command: 'Optional[str]', build_command_env: 'dict[str, str]',
dist_glob_patterns: 'Tuple[str, ...]', upload_to_vcs_release: 'bool', global_cli_options:
'GlobalCommandLineOptions', masker: 'MaskingFilter')
Bases: object
allow_zero_version: bool
apply_log_masking(masker: MaskingFilter) -> MaskingFilter
assets: List[str]
build_command: str | None
build_command_env: dict[str, str]
changelog_excluded_commit_patterns: Tuple[Pattern[str], ...]
changelog_file: Path
changelog_insertion_flag: str
changelog_mask_initial_release: bool
changelog_mode: ChangelogMode
changelog_output_format: ChangelogOutputFormat
changelog_style: str
commit_author: Actor
commit_message: str
commit_parser: CommitParser[ParsedCommit | ParseError, ParserOptions]
dist_glob_patterns: Tuple[str, ...]
classmethod from_raw_config(raw: RawConfig, global_cli_options: GlobalCommandLineOptions) ->
RuntimeContext
global_cli_options: GlobalCommandLineOptions
hvcs_client: HvcsBase
ignore_token_for_push: bool
major_on_zero: bool
masker: MaskingFilter
no_git_verify: bool
prerelease: bool
project_metadata: dict[str, Any]
repo_dir: Path
static resolve_from_env(param: EnvConfigVar | str | None) -> str | None
static select_branch_options(choices: Dict[str, BranchConfig], active_branch: str) -> BranchConfig
template_dir: Path
template_environment: Environment
upload_to_vcs_release: bool
version_declarations: Tuple[IVersionReplacer, ...]
version_translator: VersionTranslator
semantic_release.cli.const module
semantic_release.cli.github_actions_output module
class semantic_release.cli.github_actions_output.VersionGitHubActionsOutput(released: bool | None = None,
version: Version | None = None)
Bases: object
OUTPUT_ENV_VAR = 'GITHUB_OUTPUT'
property is_prerelease: bool | None
property released: bool | None
property tag: str | None
to_output_text() -> str
property version: Version | None
write_if_possible(filename: str | None = None) -> None
semantic_release.cli.masking_filter module
class semantic_release.cli.masking_filter.MaskingFilter(_use_named_masks: bool = False, **patterns:
Iterable[str | Pattern[str]])
Bases: Filter
REPLACE_STR = '****'
add_mask_for(data: str, name: str = 'redacted') -> MaskingFilter
filter(record: LogRecord) -> bool
Determine if the specified record is to be logged.
Returns True if the record should be logged, or False otherwise. If deemed appropriate,
the record may be modified in-place.
mask(msg: str) -> str
semantic_release.cli.util module
Utilities for command-line functionality
semantic_release.cli.util.indented(msg: str, prefix: str = ' ') -> str
Convenience function for text-formatting for the console.
Ensures the least indented line of the msg string is indented by prefix with consistent alignment
of the remainder of msg irrespective of the level of indentation in the Python source code
semantic_release.cli.util.load_raw_config_file(config_file: Path | str) -> dict[Any, Any]
Load raw configuration as a dict from the filename specified by config_filename, trying the
following parsing methods:
1. try to parse with tomli.load (guessing it's a TOML file)
2. try to parse with json.load (guessing it's a JSON file)
3. raise InvalidConfiguration if none of the above parsing methods work
This function will also raise FileNotFoundError if it is raised while trying to read the specified
configuration file
semantic_release.cli.util.noop_report(msg: str) -> None
Rich-prints a msg with a standard prefix to report when an action is not being taken due to a
"noop" flag
semantic_release.cli.util.parse_toml(raw_text: str) -> dict[Any, Any]
Attempts to parse raw configuration for semantic_release using tomlkit.loads, raising
InvalidConfiguration if the TOML is invalid or there's no top level "semantic_release" or
"tool.semantic_release" keys
semantic_release.cli.util.rprint(msg: str) -> None
Rich-prints to stderr so that redirection of command output isn't cluttered
semantic_release.commit_parser package
Submodules
semantic_release.commit_parser.angular module
Angular commit style parser ‐
https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines
class semantic_release.commit_parser.angular.AngularCommitParser(options: AngularParserOptions | None =
None)
Bases: CommitParser[ParsedCommit | ParseError, AngularParserOptions]
A commit parser for projects conforming to the angular style of conventional commits. See ‐
https://www.conventionalcommits.org/en/v1.0.0-beta.4/
commit_body_components_separator(accumulator: dict[str, list[str]], text: str) -> dict[str,
list[str]]
static get_default_options() -> AngularParserOptions
static is_merge_commit(commit: Commit) -> bool
parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits,
each of which will be parsed separately. Single commits will be returned as a list of a
single ParseResult.
parse_commit(commit: Commit) -> ParsedCommit | ParseError
parse_message(message: str) -> ParsedMessageResult | None
parser_options
alias of AngularParserOptions
unsquash_commit(commit: Commit) -> list[Commit]
unsquash_commit_message(message: str) -> list[str]
class semantic_release.commit_parser.angular.AngularParserOptions(minor_tags: Tuple[str, ...] =
('feat',), patch_tags: Tuple[str, ...] = ('fix', 'perf'), other_allowed_tags: Tuple[str, ...] = ('build',
'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str, ...] = ('feat', 'fix',
'perf', 'build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), default_bump_level: LevelBump =
LevelBump.NO_RELEASE, parse_squash_commits: bool = False, ignore_merge_commits: bool = False)
Bases: ParserOptions
Options dataclass for AngularCommitParser
allowed_tags: Tuple[str, ...] = ('feat', 'fix', 'perf', 'build', 'chore', 'ci', 'docs', 'style',
'refactor', 'test')
All commit-type prefixes that are allowed.
These are used to identify a valid commit message. If a commit message does not start with
one of these prefixes, it will not be considered a valid commit message.
default_bump_level: LevelBump = 0
The minimum bump level to apply to valid commit message.
ignore_merge_commits: bool = False
Toggle flag for whether or not to ignore merge commits
minor_tags: Tuple[str, ...] = ('feat',)
Commit-type prefixes that should result in a minor release bump.
other_allowed_tags: Tuple[str, ...] = ('build', 'chore', 'ci', 'docs', 'style', 'refactor',
'test')
Commit-type prefixes that are allowed but do not result in a version bump.
parse_squash_commits: bool = False
Toggle flag for whether or not to parse squash commits
patch_tags: Tuple[str, ...] = ('fix', 'perf')
Commit-type prefixes that should result in a patch release bump.
property tag_to_level: dict[str, LevelBump]
A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.conventional module
class semantic_release.commit_parser.conventional.ConventionalCommitParser(options:
ConventionalCommitParserOptions | None = None)
Bases: AngularCommitParser
A commit parser for projects conforming to the conventional commits specification.
See https://www.conventionalcommits.org/en/v1.0.0/
static get_default_options() -> ConventionalCommitParserOptions
parser_options
alias of ConventionalCommitParserOptions
class semantic_release.commit_parser.conventional.ConventionalCommitParserOptions(minor_tags: Tuple[str,
...] = ('feat',), patch_tags: Tuple[str, ...] = ('fix', 'perf'), other_allowed_tags: Tuple[str, ...] =
('build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str, ...] = ('feat',
'fix', 'perf', 'build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), default_bump_level:
LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = False, ignore_merge_commits: bool = False)
Bases: AngularParserOptions
Options dataclass for the ConventionalCommitParser.
semantic_release.commit_parser.emoji module
Commit parser which looks for emojis to determine the type of commit
class semantic_release.commit_parser.emoji.EmojiCommitParser(options: EmojiParserOptions | None = None)
Bases: CommitParser[ParsedCommit | ParseError, EmojiParserOptions]
Parse a commit using an emoji in the subject line. When multiple emojis are encountered, the one
with the highest bump level is used. If there are multiple emojis on the same level, the we use
the one listed earliest in the configuration. If the message does not contain any known emojis,
then the level to bump will be 0 and the type of change "Other". This parser never raises
UnknownCommitMessageStyleError. Emojis are not removed from the description, and will appear
alongside the commit subject in the changelog.
commit_body_components_separator(accumulator: dict[str, list[str]], text: str) -> dict[str,
list[str]]
static get_default_options() -> EmojiParserOptions
static is_merge_commit(commit: Commit) -> bool
parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
Parse a commit message
If the commit message is a squashed merge commit, it will be split into multiple commits,
each of which will be parsed separately. Single commits will be returned as a list of a
single ParseResult.
parse_commit(commit: Commit) -> ParsedCommit | ParseError
parse_message(message: str) -> ParsedMessageResult
parser_options
alias of EmojiParserOptions
unsquash_commit(commit: Commit) -> list[Commit]
unsquash_commit_message(message: str) -> list[str]
class semantic_release.commit_parser.emoji.EmojiParserOptions(major_tags: Tuple[str, ...] = (':boom:',),
minor_tags: Tuple[str, ...] = (':sparkles:', ':children_crossing:', ':lipstick:', ':iphone:', ':egg:',
':chart_with_upwards_trend:'), patch_tags: Tuple[str, ...] = (':ambulance:', ':lock:', ':bug:', ':zap:',
':goal_net:', ':alien:', ':wheelchair:', ':speech_balloon:', ':mag:', ':apple:', ':penguin:',
':checkered_flag:', ':robot:', ':green_apple:'), other_allowed_tags: Tuple[str, ...] = (':memo:',
':checkmark:'), allowed_tags: Tuple[str, ...] = (':boom:', ':sparkles:', ':children_crossing:',
':lipstick:', ':iphone:', ':egg:', ':chart_with_upwards_trend:', ':ambulance:', ':lock:', ':bug:',
':zap:', ':goal_net:', ':alien:', ':wheelchair:', ':speech_balloon:', ':mag:', ':apple:', ':penguin:',
':checkered_flag:', ':robot:', ':green_apple:', ':memo:', ':checkmark:'), default_bump_level: LevelBump =
LevelBump.NO_RELEASE, parse_linked_issues: bool = False, parse_squash_commits: bool = False,
ignore_merge_commits: bool = False)
Bases: ParserOptions
Options dataclass for EmojiCommitParser
allowed_tags: Tuple[str, ...] = (':boom:', ':sparkles:', ':children_crossing:', ':lipstick:',
':iphone:', ':egg:', ':chart_with_upwards_trend:', ':ambulance:', ':lock:', ':bug:', ':zap:',
':goal_net:', ':alien:', ':wheelchair:', ':speech_balloon:', ':mag:', ':apple:', ':penguin:',
':checkered_flag:', ':robot:', ':green_apple:', ':memo:', ':checkmark:')
All commit-type prefixes that are allowed.
default_bump_level: LevelBump = 0
The minimum bump level to apply to valid commit message.
ignore_merge_commits: bool = False
Toggle flag for whether or not to ignore merge commits
major_tags: Tuple[str, ...] = (':boom:',)
Commit-type prefixes that should result in a major release bump.
minor_tags: Tuple[str, ...] = (':sparkles:', ':children_crossing:', ':lipstick:', ':iphone:',
':egg:', ':chart_with_upwards_trend:')
Commit-type prefixes that should result in a minor release bump.
other_allowed_tags: Tuple[str, ...] = (':memo:', ':checkmark:')
Commit-type prefixes that are allowed but do not result in a version bump.
parse_linked_issues: bool = False
Whether to parse linked issues from the commit message.
Issue identification is not defined in the Gitmoji specification, so this parser will not
attempt to parse issues by default. If enabled, the parser will use the same identification
as GitHub, GitLab, and BitBucket use for linking issues, which is to look for a git commit
message footer starting with "Closes:", "Fixes:", or "Resolves:" then a space, and then the
issue identifier. The line prefix can be singular or plural and it is not case-sensitive
but must have a colon and a whitespace separator.
parse_squash_commits: bool = False
Toggle flag for whether or not to parse squash commits
patch_tags: Tuple[str, ...] = (':ambulance:', ':lock:', ':bug:', ':zap:', ':goal_net:', ':alien:',
':wheelchair:', ':speech_balloon:', ':mag:', ':apple:', ':penguin:', ':checkered_flag:',
':robot:', ':green_apple:')
Commit-type prefixes that should result in a patch release bump.
property tag_to_level: dict[str, LevelBump]
A mapping of commit tags to the level bump they should result in.
semantic_release.commit_parser.scipy module
Parses commit messages using scipy tags of the form:
<tag>(<scope>): <subject>
<body>
The elements <tag>, <scope> and <body> are optional. If no tag is present, the commit will be added to
the changelog section "None" and no version increment will be performed.
While <scope> is supported here it isn't actually part of the scipy style. If it is missing, parentheses
around it are too. The commit should then be of the form:
<tag>: <subject>
<body>
To communicate a breaking change add "BREAKING CHANGE" into the body at the beginning of a paragraph.
Fill this paragraph with information how to migrate from the broken behavior to the new behavior. It will
be added to the "Breaking" section of the changelog.
Supported Tags:
(
API,
DEP,
ENH,
REV,
BUG,
MAINT,
BENCH,
BLD,
)
DEV, DOC, STY, TST, REL, FEAT, TEST
Supported Changelog Sections:
breaking, feature, fix, Other, None
class semantic_release.commit_parser.scipy.ScipyCommitParser(options: ScipyParserOptions | None = None)
Bases: AngularCommitParser
Parser for scipy-style commit messages
static get_default_options() -> ScipyParserOptions
parse_message(message: str) -> ParsedMessageResult | None
parser_options
alias of ScipyParserOptions
class semantic_release.commit_parser.scipy.ScipyParserOptions(minor_tags: Tuple[str, ...] = ('DEP',
'DEV', 'ENH', 'REV', 'FEAT'), patch_tags: Tuple[str, ...] = ('BLD', 'BUG', 'MAINT'), other_allowed_tags:
Tuple[str, ...] = ('build', 'chore', 'ci', 'docs', 'style', 'refactor', 'test'), allowed_tags: Tuple[str,
...] = ('API', 'DEP', 'DEV', 'ENH', 'REV', 'FEAT', 'BLD', 'BUG', 'MAINT', 'BENCH', 'DOC', 'STY', 'TST',
'REL', 'TEST'), default_bump_level: LevelBump = LevelBump.NO_RELEASE, parse_squash_commits: bool = False,
ignore_merge_commits: bool = False, major_tags: Tuple[str, ...] = ('API',), default_level_bump: LevelBump
= LevelBump.NO_RELEASE)
Bases: AngularParserOptions
Options dataclass for ScipyCommitParser
Scipy-style commit messages follow the same format as Angular-style commit just with different tag
names.
allowed_tags: Tuple[str, ...] = ('API', 'DEP', 'DEV', 'ENH', 'REV', 'FEAT', 'BLD', 'BUG', 'MAINT',
'BENCH', 'DOC', 'STY', 'TST', 'REL', 'TEST')
All commit-type prefixes that are allowed.
These are used to identify a valid commit message. If a commit message does not start with
one of these prefixes, it will not be considered a valid commit message.
default_level_bump: LevelBump = 0
The minimum bump level to apply to valid commit message.
major_tags: Tuple[str, ...] = ('API',)
Commit-type prefixes that should result in a major release bump.
minor_tags: Tuple[str, ...] = ('DEP', 'DEV', 'ENH', 'REV', 'FEAT')
Commit-type prefixes that should result in a minor release bump.
patch_tags: Tuple[str, ...] = ('BLD', 'BUG', 'MAINT')
Commit-type prefixes that should result in a patch release bump.
semantic_release.commit_parser.tag module
Legacy commit parser from Python Semantic Release 1.0
class semantic_release.commit_parser.tag.TagCommitParser(options: _OPTS | None = None)
Bases: CommitParser[ParsedCommit | ParseError, TagParserOptions]
Parse a commit message according to the 1.0 version of python-semantic-release. It expects a tag
of some sort in the commit message and will use the rest of the first line as changelog content.
static get_default_options() -> TagParserOptions
parse(commit: Commit) -> ParsedCommit | ParseError | list[ParsedCommit | ParseError]
parser_options
alias of TagParserOptions
class semantic_release.commit_parser.tag.TagParserOptions(minor_tag: str = ':sparkles:', patch_tag: str =
':nut_and_bolt:')
Bases: ParserOptions
minor_tag: str = ':sparkles:'
patch_tag: str = ':nut_and_bolt:'
semantic_release.commit_parser.token module
class semantic_release.commit_parser.token.ParseError(commit: Commit, error: str)
Bases: NamedTuple
A read-only named tuple object representing an error that occurred while parsing a commit message.
commit: Commit
The original commit object (a class defined by GitPython) that was parsed
error: str
A string with a description for why the commit parsing failed.
property hexsha: str
A hex representation of the hash value of the commit.
This is a pass through property for convience to access the hexsha attribute of the commit.
is_merge_commit() -> bool
property message: str
A string representation of the commit message.
This is a pass through property for convience to access the message attribute of the commit
object.
If the message is of type bytes then it will be decoded to a UTF-8 string.
raise_error() -> NoReturn
A convience method to raise a CommitParseError with the error message.
property short_hash: str
A short representation of the hash value (in hex) of the commit.
class semantic_release.commit_parser.token.ParsedCommit(bump: LevelBump, type: str, scope: str,
descriptions: list[str], breaking_descriptions: list[str], commit: Commit, release_notices: tuple[str,
...] = (), linked_issues: tuple[str, ...] = (), linked_merge_request: str = '', include_in_changelog:
bool = True)
Bases: NamedTuple
A read-only named tuple object representing the result of parsing a commit message.
breaking_descriptions: list[str]
A list of paragraphs which are deemed to identify and describe breaking changes by the
parser.
An example would be a paragraph which begins with the text BREAKING CHANGE: in the commit
message but the parser gennerally strips the prefix and includes the rest of the paragraph
in this list.
bump: LevelBump
A LevelBump enum value indicating what type of change this commit introduces.
commit: Commit
The original commit object (a class defined by GitPython) that was parsed
descriptions: list[str]
A list of paragraphs from the commit message.
Paragraphs are generally delimited by a double-newline since git commit messages are
sometimes manually wordwrapped with a single newline, but this is up to the parser to
implement.
static from_parsed_message_result(commit: Commit, parsed_message_result: ParsedMessageResult) ->
ParsedCommit
A convience method to create a ParsedCommit object from a ParsedMessageResult object and a
Commit object.
property hexsha: str
A hex representation of the hash value of the commit.
This is a pass through property for convience to access the hexsha attribute of the commit.
include_in_changelog: bool
A boolean value indicating whether this commit should be included in the changelog.
This enables parsers to flag commits which are not user-facing or are otherwise not
relevant to the changelog to be filtered out by PSR's internal algorithms.
is_merge_commit() -> bool
linked_issues: tuple[str, ...]
A tuple of issue numbers as strings, if the commit is contains issue references.
If there are no issue references, this should be an empty tuple. Although, we generally
refer to them as "issue numbers", it generally should be a string to adhere to the prefixes
used by the VCS (ex. # for GitHub, GitLab, etc.) or issue tracker (ex. JIRA uses AAA-###).
linked_merge_request: str
A pull request or merge request definition, if the commit is labeled with a pull/merge
request number.
This is a string value which includes any special character prefix used by the VCS (e.g. #
for GitHub, ! for GitLab).
property linked_pull_request: str
An alias to the linked_merge_request attribute.
property message: str
A string representation of the commit message.
This is a pass through property for convience to access the message attribute of the commit
object.
If the message is of type bytes then it will be decoded to a UTF-8 string.
release_notices: tuple[str, ...]
A tuple of release notices, which are additional information about the changes that affect
the user.
An example would be a paragraph which begins with the text NOTICE: in the commit message
but the parser generally strips the prefix and includes the rest of the paragraph in this
list.
scope: str
The scope, as a string, parsed from the commit.
Generally an optional field based on the commit message style which means it very likely
can be an empty string. Commit styles which do not have a meaningful concept of "scope"
usually fill this field with an empty string.
property short_hash: str
A short representation of the hash value (in hex) of the commit.
type: str
The type of the commit as a string, per the commit message style.
This is up to the parser to implement; for example, the EmojiCommitParser parser fills this
field with the emoji representing the most significant change for the commit.
class semantic_release.commit_parser.token.ParsedMessageResult(bump: LevelBump, type: str, category: str,
scope: str, descriptions: tuple[str, ...], breaking_descriptions: tuple[str, ...] = (), release_notices:
tuple[str, ...] = (), linked_issues: tuple[str, ...] = (), linked_merge_request: str = '',
include_in_changelog: bool = True)
Bases: NamedTuple
A read-only named tuple object representing the result from parsing a commit message.
Essentially this is a data structure which holds the parsed information from a commit message
without the actual commit object itself. Very helpful for unit testing.
Most of the fields will replicate the fields of a ParsedCommit
breaking_descriptions: tuple[str, ...]
Alias for field number 5
bump: LevelBump
Alias for field number 0
category: str
Alias for field number 2
descriptions: tuple[str, ...]
Alias for field number 4
include_in_changelog: bool
Alias for field number 9
linked_issues: tuple[str, ...]
Alias for field number 7
linked_merge_request: str
Alias for field number 8
release_notices: tuple[str, ...]
Alias for field number 6
scope: str
Alias for field number 3
type: str
Alias for field number 1
semantic_release.commit_parser.util module
semantic_release.commit_parser.util.deep_copy_commit(commit: Commit) -> dict[str, Any]
semantic_release.commit_parser.util.force_str(msg: str | bytes | bytearray | memoryview) -> str
semantic_release.commit_parser.util.parse_paragraphs(text: str) -> list[str]
This will take a text block and return a list containing each paragraph with single line breaks
collapsed into spaces.
To handle Windows line endings, carriage returns 'r' are removed before separating into
paragraphs.
It will attempt to detect Git footers and they will not be condensed.
Parameters
text -- The text string to be divided.
Returns
A list of condensed paragraphs, as strings.
semantic_release.hvcs package
Submodules
semantic_release.hvcs.bitbucket module
Helper code for interacting with a Bitbucket remote VCS
class semantic_release.hvcs.bitbucket.Bitbucket(remote_url: str, *, hvcs_domain: str | None = None,
hvcs_api_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **kwargs:
Any)
Bases: RemoteHvcsBase
Bitbucket HVCS interface for interacting with BitBucket repositories
This class supports the following products:
• BitBucket Cloud
• BitBucket Data Center Server (on-premises installations)
This interface does its best to detect which product is configured based on the provided domain.
If it is the official bitbucket.org, the default domain, then it is considered as BitBucket Cloud
which uses the subdomain api.bitbucket.org/2.0 for api communication.
If the provided domain is anything else, than it is assumed to be communicating with an on-premise
or 3rd-party maintained BitBucket instance which matches with the BitBucket Data Center Server
product. The on-prem server product uses a path prefix for handling api requests which is
configured to be server.domain/rest/api/1.0 based on the documentation in April 2024.
DEFAULT_API_PATH_CLOUD = '/2.0'
DEFAULT_API_PATH_ONPREM = '/rest/api/1.0'
DEFAULT_API_SUBDOMAIN_PREFIX = 'api'
DEFAULT_API_URL_CLOUD = 'https://api.bitbucket.org/2.0'
DEFAULT_DOMAIN = 'bitbucket.org'
DEFAULT_ENV_TOKEN_NAME = 'BITBUCKET_TOKEN'
OFFICIAL_NAME = 'Bitbucket'
commit_hash_url(commit_hash: str) -> str
compare_url(from_rev: str, to_rev: str) -> str
Get the Bitbucket comparison link between two version tags. :param from_rev: The older
version to compare. :param to_rev: The newer version to compare. :return: Link to view a
comparison between the two versions.
create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int | str
Create or update a release for the given tag in a remote VCS, attaching the given
changelog, if supported
create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None =
None, noop: bool = False) -> int | str
Create a release in a remote VCS, if supported
Which includes uploading any assets as part of the release
static format_w_official_vcs_name(format_str: str) -> str
get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
Return a list of functions that can be used as filters in a Jinja2 template
ex. filters to convert text to URLs for issues and commits
pull_request_url(pr_number: str | int) -> str
remote_url(use_token: bool = True) -> str
Get the remote url including the token for authentication if requested
upload_dists(tag: str, dist_glob: str) -> int
Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.gitea module
Helper code for interacting with a Gitea remote VCS
class semantic_release.hvcs.gitea.Gitea(remote_url: str, *, hvcs_domain: str | None = None, token: str |
None = None, allow_insecure: bool = False, **_kwargs: Any)
Bases: RemoteHvcsBase
Gitea helper class
DEFAULT_API_PATH = '/api/v1'
DEFAULT_DOMAIN = 'gitea.com'
DEFAULT_ENV_TOKEN_NAME = 'GITEA_TOKEN'
OFFICIAL_NAME = 'Gitea'
asset_upload_url(release_id: str) -> str
Get the correct upload url for a release ‐
https://gitea.com/api/swagger#/repository/repoCreateReleaseAttachment :param release_id: ID
of the release to upload to
commit_hash_url(commit_hash: str) -> str
create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int
Post release changelog :param version: The version number :param changelog: The release
notes for this version
Returns
The status of the request
create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None =
None, noop: bool = False) -> int
Create a new release
Ref: https://gitea.com/api/swagger#/repository/repoCreateRelease
Parameters
• tag -- Tag to create release for
• release_notes -- The release notes for this version
• prerelease -- Whether or not this release should be specified as a prerelease
Returns
Whether the request succeeded
create_release_url(tag: str = '') -> str
edit_release_notes(release_id: int, release_notes: str) -> int
Edit a release with updated change notes ‐
https://gitea.com/api/swagger#/repository/repoEditRelease :param id: ID of release to
update :param release_notes: The release notes for this version
Returns
The ID of the release that was edited
static format_w_official_vcs_name(format_str: str) -> str
get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
Return a list of functions that can be used as filters in a Jinja2 template
ex. filters to convert text to URLs for issues and commits
get_release_id_by_tag(tag: str) -> int | None
Get a release by its tag name https://gitea.com/api/swagger#/repository/repoGetReleaseByTag
:param tag: Tag to get release for
Returns
ID of found release
issue_url(issue_num: str | int) -> str
pull_request_url(pr_number: str | int) -> str
remote_url(use_token: bool = True) -> str
Get the remote url including the token for authentication if requested
upload_dists(tag: str, dist_glob: str) -> int
Upload distributions to a release :param tag: Tag to upload for :param path: Path to the
dist directory
Returns
The number of distributions successfully uploaded
upload_release_asset(release_id: int, file: str, label: str | None = None) -> bool
Upload an asset to an existing release ‐
https://gitea.com/api/swagger#/repository/repoCreateReleaseAttachment :param release_id: ID
of the release to upload to :param file: Path of the file to upload :param label: this
parameter has no effect
Returns
The status of the request
semantic_release.hvcs.github module
Helper code for interacting with a GitHub remote VCS
class semantic_release.hvcs.github.Github(remote_url: str, *, hvcs_domain: str | None = None,
hvcs_api_domain: str | None = None, token: str | None = None, allow_insecure: bool = False, **_kwargs:
Any)
Bases: RemoteHvcsBase
GitHub HVCS interface for interacting with GitHub repositories
This class supports the following products:
• GitHub Free, Pro, & Team
• GitHub Enterprise Cloud
• GitHub Enterprise Server (on-premises installations)
This interface does its best to detect which product is configured based on the provided domain.
If it is the official github.com, the default domain, then it is considered as GitHub Enterprise
Cloud which uses the subdomain api.github.com for api communication.
If the provided domain is anything else, than it is assumed to be communicating with an on-premise
or 3rd-party maintained GitHub instance which matches with the GitHub Enterprise Server product.
The on-prem server product uses a path prefix for handling api requests which is configured to be
server.domain/api/v3 based on the documentation in April 2024.
DEFAULT_API_DOMAIN = 'api.github.com'
DEFAULT_API_PATH_CLOUD = '/'
DEFAULT_API_PATH_ONPREM = '/api/v3'
DEFAULT_API_SUBDOMAIN_PREFIX = 'api'
DEFAULT_API_URL_CLOUD = 'https://api.github.com'
DEFAULT_DOMAIN = 'github.com'
DEFAULT_ENV_TOKEN_NAME = 'GH_TOKEN'
OFFICIAL_NAME = 'GitHub'
asset_upload_url(release_id: str) -> str | None
Get the correct upload url for a release ‐
https://docs.github.com/en/enterprise-server@3.5/rest/releases/releases#get-a-release
:param release_id: ID of the release to upload to :return: URL to upload for a release if
found, else None
commit_hash_url(commit_hash: str) -> str
compare_url(from_rev: str, to_rev: str) -> str
Get the GitHub comparison link between two version tags. :param from_rev: The older
version to compare. :param to_rev: The newer version to compare. :return: Link to view a
comparison between the two versions.
create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int
Post release changelog :param tag: The version number :param release_notes: The release
notes for this version :param prerelease: Whether or not this release should be created as
a prerelease :return: The status of the request
create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None =
None, noop: bool = False) -> int
Create a new release
REF: https://docs.github.com/rest/reference/repos#create-a-release
Parameters
• tag -- Tag to create release for
• release_notes -- The release notes for this version
• prerelease -- Whether or not this release should be created as a prerelease
• assets -- a list of artifacts to upload to the release
Returns
the ID of the release
create_release_url(tag: str = '') -> str
edit_release_notes(release_id: int, release_notes: str) -> int
Edit a release with updated change notes ‐
https://docs.github.com/rest/reference/repos#update-a-release :param release_id: ID of
release to update :param release_notes: The release notes for this version :return: The ID
of the release that was edited
static format_w_official_vcs_name(format_str: str) -> str
get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
Return a list of functions that can be used as filters in a Jinja2 template
ex. filters to convert text to URLs for issues and commits
get_release_id_by_tag(tag: str) -> int | None
Get a release by its tag name ‐
https://docs.github.com/rest/reference/repos#get-a-release-by-tag-name :param tag: Tag to
get release for :return: ID of release, if found, else None
issue_url(issue_num: str | int) -> str
pull_request_url(pr_number: str | int) -> str
remote_url(use_token: bool = True) -> str
Get the remote url including the token for authentication if requested
upload_dists(tag: str, dist_glob: str) -> int
Upload distributions to a release :param tag: Version to upload for :param dist_glob: Path
to the dist directory :return: The number of distributions successfully uploaded
upload_release_asset(release_id: int, file: str, label: str | None = None) -> bool
Upload an asset to an existing release ‐
https://docs.github.com/rest/reference/repos#upload-a-release-asset :param release_id: ID
of the release to upload to :param file: Path of the file to upload :param label: Optional
custom label for this file :return: The status of the request
semantic_release.hvcs.gitlab module
Helper code for interacting with a Gitlab remote VCS
class semantic_release.hvcs.gitlab.Gitlab(remote_url: str, *, hvcs_domain: str | None = None, token: str
| None = None, allow_insecure: bool = False, **_kwargs: Any)
Bases: RemoteHvcsBase
Gitlab HVCS interface for interacting with Gitlab repositories
DEFAULT_DOMAIN = 'gitlab.com'
DEFAULT_ENV_TOKEN_NAME = 'GITLAB_TOKEN'
OFFICIAL_NAME = 'GitLab'
commit_hash_url(commit_hash: str) -> str
compare_url(from_rev: str, to_rev: str) -> str
create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> str
Create or update a release for the given tag in a remote VCS.
Parameters
• tag -- The tag to create or update the release for
• release_notes -- The changelog description for this version only
• prerelease -- This parameter has no effect in GitLab
Returns
The release id
Raises
• ValueError -- If the release could not be created or updated
• gitlab.exceptions.GitlabAuthenticationError -- If the user is not authenticated
• GitlabUpdateError -- If the server cannot perform the request
create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str] | None =
None, noop: bool = False) -> str
Create a release in a remote VCS, adding any release notes and assets to it
Parameters
• tag -- The tag to create the release for
• release_notes -- The changelog description for this version only
• prerelease -- This parameter has no effect in GitLab
• assets -- A list of paths to files to upload as assets (TODO: not implemented)
• noop -- If True, do not perform any actions, only log intents
Returns
The tag of the release
Raises GitlabAuthenticationError: If authentication is not correct
Raises GitlabCreateError: If the server cannot perform the request
create_release_url(tag: str = '') -> str
edit_release_notes(release: ProjectRelease, release_notes: str) -> str
Update the release notes for a given release.
Parameters
• release -- The release object to update
• release_notes -- The new release notes
Returns
The release id
Raises GitlabAuthenticationError: If authentication is not correct
Raises GitlabUpdateError: If the server cannot perform the request
static format_w_official_vcs_name(format_str: str) -> str
get_changelog_context_filters() -> tuple[Callable[..., Any], ...]
Return a list of functions that can be used as filters in a Jinja2 template
ex. filters to convert text to URLs for issues and commits
get_release_by_tag(tag: str) -> ProjectRelease | None
Get a release by its tag name.
Parameters
tag -- The tag name to get the release for
Returns
gitlab.v4.objects.ProjectRelease or None if not found
Raises gitlab.exceptions.GitlabAuthenticationError: If the user is not authenticated
issue_url(issue_num: str | int) -> str
merge_request_url(mr_number: str | int) -> str
property project: GitLabProject
pull_request_url(pr_number: str | int) -> str
remote_url(use_token: bool = True) -> str
Get the remote url including the token for authentication if requested
upload_dists(tag: str, dist_glob: str) -> int
Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.remote_hvcs_base module
Common functionality and interface for interacting with Git remote VCS
class semantic_release.hvcs.remote_hvcs_base.RemoteHvcsBase(remote_url: str, *_args: Any, **_kwargs: Any)
Bases: HvcsBase
Interface for subclasses interacting with a remote VCS
This abstract class is defined to provide common helper functions and a set of basic methods that
all remote VCS environments usually support.
If the remote vcs implementation (via subclass) does not support a functionality then it can just
call super()'s method which defaults as a non-supported log message and empty results. This is
more straightforward than checking for NotImplemented around every function call in the core
library code.
DEFAULT_ENV_TOKEN_NAME = 'HVCS_TOKEN'
property api_url: Url
create_api_url(endpoint: str, auth: str | None = None, query: str | None = None, fragment: str |
None = None) -> str
abstract create_or_update_release(tag: str, release_notes: str, prerelease: bool = False) -> int |
str
Create or update a release for the given tag in a remote VCS, attaching the given
changelog, if supported
abstract create_release(tag: str, release_notes: str, prerelease: bool = False, assets: list[str]
| None = None, noop: bool = False) -> int | str
Create a release in a remote VCS, if supported
Which includes uploading any assets as part of the release
create_repo_url(repo_path: str, query: str | None = None, fragment: str | None = None) -> str
create_server_url(path: str, auth: str | None = None, query: str | None = None, fragment: str |
None = None) -> str
property hvcs_domain: Url
abstract upload_dists(tag: str, dist_glob: str) -> int
Upload built distributions to a release on a remote VCS that supports such uploads
semantic_release.hvcs.token_auth module
class semantic_release.hvcs.token_auth.TokenAuth(token: str)
Bases: AuthBase
requests Authentication for token based authorization. This allows us to attach the Authorization
header with a token to a session.
semantic_release.hvcs.util module
semantic_release.hvcs.util.build_requests_session(raise_for_status: bool = True, retry: bool | int |
Retry = True, auth: TokenAuth | None = None) -> Session
Create a requests session.
Parameters
• raise_for_status -- If True, a hook to invoke raise_for_status be installed
• retry -- If true, it will use default Retry configuration. if an integer, it will use
default Retry configuration with given integer as total retry count. if Retry instance,
it will use this instance.
• auth -- Optional TokenAuth instance to be used to provide the Authorization header to the
session
Returns
configured requests Session
semantic_release.hvcs.util.suppress_http_error_for_codes(*codes: int) -> Callable[[Callable[[...], _R]],
Callable[[...], _R | None]]
For the codes given, return a decorator that will suppress HTTPErrors that are raised from
responses that came with one of those status codes. The function will return False instead of
raising the HTTPError
semantic_release.hvcs.util.suppress_not_found(func: Callable[[...], _R]) -> Callable[[...], _R | None]
semantic_release.version package
Subpackages
semantic_release.version.declarations package
Submodules
semantic_release.version.declarations.enum module
class semantic_release.version.declarations.enum.VersionStampType(value, names=<not given>, *values,
module=None, qualname=None, type=None, start=1, boundary=None)
Bases: str, Enum
Enum for the type of version declaration
NUMBER_FORMAT = 'nf'
TAG_FORMAT = 'tf'
semantic_release.version.declarations.i_version_replacer module
class semantic_release.version.declarations.i_version_replacer.IVersionReplacer
Bases: object
Interface for subclasses that replace a version string in a source file.
Methods generally have a base implementation are implemented here but likely just provide a
not-supported message but return gracefully
This class cannot be instantiated directly but must be inherited from and implement the designated
abstract methods.
abstract parse() -> set[Version]
Return a set of the versions which can be parsed from the file. Because a source can match
in multiple places, this method returns a set of matches. Generally, there should only be
one element in this set (i.e. even if the version is specified in multiple places, it
should be the same version in each place), but enforcing that condition is not mandatory or
expected.
abstract replace(new_version: Version) -> str
Replace the version in the source content with new_version, and return the updated content.
Parameters
new_version -- The new version number as a Version instance
abstract update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
This method reads the underlying file, replaces each occurrence of the matched pattern,
then writes the updated file.
Parameters
new_version -- The new version number as a Version instance
semantic_release.version.declarations.pattern module
class semantic_release.version.declarations.pattern.PatternVersionDeclaration(path: Path | str,
search_text: str, stamp_format: VersionStampType)
Bases: IVersionReplacer
VersionDeclarationABC implementation representing a version number in a particular file. The
version number is identified by a regular expression, which should be provided in search_text.
property content: str
A cached property that stores the content of the configured source file.
classmethod from_string_definition(replacement_def: str, tag_format: str) ->
PatternVersionDeclaration
create an instance of self from a string representing one item of the "version_variables"
list in the configuration
parse() -> set[Version]
Return the versions matching this pattern. Because a pattern can match in multiple places,
this method returns a set of matches. Generally, there should only be one element in this
set (i.e. even if the version is specified in multiple places, it should be the same
version in each place), but it falls on the caller to check for this condition.
Deprecated since version 9.20.0: Function is unused and will be removed in a future release
replace(new_version: Version) -> str
Replace the version in the source content with new_version, and return the updated content.
Parameters
new_version -- The new version number as a Version instance
update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
This method reads the underlying file, replaces each occurrence of the matched pattern,
then writes the updated file.
Parameters
new_version -- The new version number as a Version instance
class semantic_release.version.declarations.pattern.VersionSwapper(new_version_str: str,
group_match_name: str)
Bases: object
Callable to replace a version number in a string with a new version number.
semantic_release.version.declarations.toml module
class semantic_release.version.declarations.toml.TomlVersionDeclaration(path: Path | str, search_text:
str, stamp_format: VersionStampType)
Bases: IVersionReplacer
property content: str
A cached property that stores the content of the configured source file.
classmethod from_string_definition(replacement_def: str) -> TomlVersionDeclaration
create an instance of self from a string representing one item of the "version_toml" list
in the configuration
parse() -> set[Version]
Look for the version in the source content
Deprecated since version 9.20.0: Function is unused and will be removed in a future release
replace(new_version: Version) -> str
Replace the version in the source content with new_version, and return the updated content.
update_file_w_version(new_version: Version, noop: bool = False) -> Path | None
This method reads the underlying file, replaces each occurrence of the matched pattern,
then writes the updated file.
Parameters
new_version -- The new version number as a Version instance
Submodules
semantic_release.version.algorithm module
semantic_release.version.algorithm.next_version(repo: Repo, translator: VersionTranslator, commit_parser:
CommitParser[ParseResult, ParserOptions], prerelease: bool = False, major_on_zero: bool = True,
allow_zero_version: bool = True) -> Version
Evaluate the history within repo, and based on the tags and commits in the repo history, identify
the next semantic version that should be applied to a release
semantic_release.version.algorithm.tags_and_versions(tags: Iterable[Tag], translator: VersionTranslator)
-> list[tuple[Tag, Version]]
Return a list of 2-tuples, where each element is a tuple (tag, version) from the tags in the Git
repo and their corresponding Version according to Version.from_tag. The returned list is sorted
according to semver ordering rules.
Tags which are not matched by translator are ignored.
semantic_release.version.declaration module
class semantic_release.version.declaration.VersionDeclarationABC(*args, **kwargs)
Bases: ABC
ABC for classes representing a location in which a version is declared somewhere within the source
tree of the repository
Deprecated since version 9.20.0: Refactored to composition paradigm using the new IVersionReplacer
interface. This class will be removed in a future release
property content: str
The content of the source file in which the version is stored. This property is cached in
the instance variable _content
abstract parse() -> set[Version]
Return a set of the versions which can be parsed from the file. Because a source can match
in multiple places, this method returns a set of matches. Generally, there should only be
one element in this set (i.e. even if the version is specified in multiple places, it
should be the same version in each place), but enforcing that condition is not mandatory or
expected.
abstract replace(new_version: Version) -> str
Update the versions. This method reads the underlying file, replaces each occurrence of
the matched pattern, then writes the updated file. :param new_version: The new version
number as a Version instance
write(content: str) -> None
Write new content back to the source path. Use alongside .replace(): >>> class
MyVD(VersionDeclarationABC): ... def parse(self): ... ... def replace(self,
new_version: Version): ... ... def write(self, content: str): ...
>>> new_version = Version.parse("1.2.3")
>>> vd = MyVD("path", r"__version__ = (?P<version>\d+\d+\d+)")
>>> vd.write(vd.replace(new_version))
semantic_release.version.translator module
class semantic_release.version.translator.VersionTranslator(tag_format: str = 'v{version}',
prerelease_token: str = 'rc')
Bases: object
Class to handle translation from Git tags into their corresponding Version instances.
from_string(version_str: str) -> Version
Return a Version instance from a string. Delegates directly to Version.parse, using the
translator's own stored values for tag_format and prerelease
from_tag(tag: str) -> Version | None
Return a Version instance from a Git tag, if tag_format matches the format which would have
generated the tag from a version. Otherwise return None. For example, a tag of 'v1.2.3'
should be matched if tag_format = 'v{version}, but not if tag_format = staging--v{version}.
str_to_tag(version_str: str) -> str
Formats a version string into a tag name
semantic_release.version.version module
class semantic_release.version.version.Version(major: int, minor: int, patch: int, *, prerelease_token:
str = 'rc', prerelease_revision: int | None = None, build_metadata: str = '', tag_format: str =
'v{version}')
Bases: object
as_semver_tag() -> str
as_tag() -> str
bump(level: LevelBump) -> Version
Return a new Version instance according to the level specified to bump. Note this will
intentionally drop the build metadata - that should be added elsewhere for the specific
build producing this version.
finalize_version() -> Version
property is_prerelease: bool
classmethod parse(version_str: str, tag_format: str = 'v{version}', prerelease_token: str = 'rc')
-> Version
Parse version string to a Version instance. Inspired by semver.version:VersionInfo.parse,
this implementation doesn't allow optional minor and patch versions.
Parameters
prerelease_token -- will be ignored if the version string is a prerelease, the
parsed token from version_str will be used instead.
property tag_format: str
to_prerelease(token: str | None = None, revision: int | None = None) -> Version
Submodules
semantic_release.const module
semantic_release.enums module
class semantic_release.enums.LevelBump(value, names=<not given>, *values, module=None, qualname=None,
type=None, start=1, boundary=None)
Bases: IntEnum
IntEnum representing valid types of bumps for a version. We use an IntEnum to enable ordering of
levels.
MAJOR = 4
MINOR = 3
NO_RELEASE = 0
PATCH = 2
PRERELEASE_REVISION = 1
classmethod from_string(val: str) -> LevelBump
Get the level from string representation. For backwards-compatibility, dashes are replaced
with underscores so that: >>> LevelBump.from_string("no-release") == LevelBump.NO_RELEASE
Equally, >>> LevelBump.from_string("minor") == LevelBump.MINOR
class semantic_release.enums.SemanticReleaseLogLevels(value, names=<not given>, *values, module=None,
qualname=None, type=None, start=1, boundary=None)
Bases: IntEnum
IntEnum representing the log levels used by semantic-release.
CRITICAL = 50
DEBUG = 10
ERROR = 40
FATAL = 50
INFO = 20
SILLY = 5
WARNING = 30
semantic_release.errors module
Custom Errors
exception semantic_release.errors.AssetUploadError
Bases: SemanticReleaseBaseError
Raised when there is a failure uploading an asset to a remote hvcs's release artifact storage.
exception semantic_release.errors.BuildDistributionsError
Bases: SemanticReleaseBaseError
Raised when there is a failure to build the distribution files.
exception semantic_release.errors.CommitParseError
Bases: SemanticReleaseBaseError
Raised when a commit cannot be parsed by a commit parser. Custom commit parsers should also raise
this Exception
exception semantic_release.errors.DetachedHeadGitError
Bases: SemanticReleaseBaseError
Raised when the git repository is in a detached HEAD state
exception semantic_release.errors.GitAddError
Bases: SemanticReleaseBaseError
Raised when there is a failure to add files to the git index.
exception semantic_release.errors.GitCommitEmptyIndexError
Bases: SemanticReleaseBaseError
Raised when there is an attempt to commit an empty index.
exception semantic_release.errors.GitCommitError
Bases: SemanticReleaseBaseError
Raised when there is a failure to commit the changes.
exception semantic_release.errors.GitPushError
Bases: SemanticReleaseBaseError
Raised when there is a failure to push to the git remote.
exception semantic_release.errors.GitTagError
Bases: SemanticReleaseBaseError
Raised when there is a failure to tag the release.
exception semantic_release.errors.IncompleteReleaseError
Bases: SemanticReleaseBaseError
Raised when there is a failure amongst one of the api requests when creating a release on a remote
hvcs.
exception semantic_release.errors.InternalError
Bases: SemanticReleaseBaseError
Raised when an internal error occurs, which should never happen
exception semantic_release.errors.InvalidConfiguration
Bases: SemanticReleaseBaseError
Raised when configuration is deemed invalid
exception semantic_release.errors.InvalidParserOptions
Bases: InvalidConfiguration
Raised when the parser options are invalid
exception semantic_release.errors.InvalidVersion
Bases: ValueError, SemanticReleaseBaseError
Raised when Version.parse attempts to parse a string containing an invalid version.
exception semantic_release.errors.MissingGitRemote
Bases: SemanticReleaseBaseError
Raised when repository is missing the configured remote origin or upstream
exception semantic_release.errors.MissingMergeBaseError
Bases: SemanticReleaseBaseError
Raised when the merge base cannot be found with the current history. Generally because of a
shallow git clone.
exception semantic_release.errors.NotAReleaseBranch
Bases: InvalidConfiguration
Raised when semantic_release is invoked on a branch which isn't configured for releases
exception semantic_release.errors.ParserLoadError
Bases: SemanticReleaseBaseError
Raised when there is a failure to find, load, or instantiate a custom parser definition.
exception semantic_release.errors.SemanticReleaseBaseError
Bases: Exception
Base Exception from which all other custom Exceptions defined in semantic_release inherit
exception semantic_release.errors.UnexpectedResponse
Bases: SemanticReleaseBaseError
Raised when an HTTP response cannot be parsed properly or the expected structure is not found.
semantic_release.gitproject module
Module for git related operations.
class semantic_release.gitproject.GitProject(directory: Path | str = '.', commit_author: Actor | None =
None, credential_masker: MaskingFilter | None = None)
Bases: object
git_add(paths: Sequence[Path | str], force: bool = False, strict: bool = False, noop: bool =
False) -> None
git_commit(message: str, date: int | None = None, commit_all: bool = False, no_verify: bool =
False, noop: bool = False) -> None
git_push_branch(remote_url: str, branch: str, noop: bool = False) -> None
git_push_tag(remote_url: str, tag: str, noop: bool = False) -> None
git_tag(tag_name: str, message: str, isotimestamp: str, noop: bool = False) -> None
is_dirty() -> bool
property logger: Logger
property project_root: Path
semantic_release.globals module
Semantic Release Global Variables.
semantic_release.globals.log_level: SemanticReleaseLogLevels = SemanticReleaseLogLevels.WARNING
int: Logging level for semantic-release
semantic_release.helpers module
class semantic_release.helpers.ParsedGitUrl(scheme: str, netloc: str, namespace: str, repo_name: str)
Bases: NamedTuple
Container for the elements parsed from a git URL
namespace: str
Alias for field number 2
netloc: str
Alias for field number 1
repo_name: str
Alias for field number 3
scheme: str
Alias for field number 0
semantic_release.helpers.check_tag_format(tag_format: str) -> None
semantic_release.helpers.dynamic_import(import_path: str) -> Any
Dynamically import an object from a conventionally formatted "module:attribute" string
semantic_release.helpers.format_arg(value: Any) -> str
Helper to format an argument an argument for logging
semantic_release.helpers.get_number_from_str(string: str, default: int = -1, interpret_hex: bool = False)
-> int
semantic_release.helpers.logged_function(logger: Logger) -> Callable[[Callable[[...], _R]],
Callable[[...], _R]]
Decorator which adds debug logging of a function's input arguments and return value.
The input arguments are logged before the function is called, and the return value is logged once
it has completed.
Parameters
logger -- Logger to send output to.
semantic_release.helpers.parse_git_url(url: str) -> ParsedGitUrl
Attempt to parse a string as a git url http[s]://, git://, file://, or ssh format, into a
ParsedGitUrl.
supported examples:
http://git.mycompany.com/username/myproject.git https://github.com/username/myproject.git ‐
https://gitlab.com/group/subgroup/myproject.git ‐
https://git.mycompany.com:4443/username/myproject.git git://host.xz/path/to/repo.git/
git://host.xz:9418/path/to/repo.git/ git@github.com:username/myproject.git
<-- assumes ssh:// ssh://git@github.com:3759/myproject.git <-- non-standard,
but assume user 3759 ssh://git@github.com:username/myproject.git
ssh://git@bitbucket.org:7999/username/myproject.git
git+ssh://git@github.com:username/myproject.git /Users/username/dev/remote/myproject.git
<-- Posix File paths file:///Users/username/dev/remote/myproject.git
C:/Users/username/dev/remote/myproject.git <-- Windows File paths
file:///C:/Users/username/dev/remote/myproject.git
REFERENCE: https://stackoverflow.com/questions/31801271/what-are-the-supported-git-url-formats
Raises ValueError if the url can't be parsed.
semantic_release.helpers.sort_numerically(iterable: Iterable[str], reverse: bool = False, allow_hex: bool
= False) -> list[str]
semantic_release.helpers.text_reducer(text: str, filter_pair: tuple[Pattern[str], str]) -> str
Reduce function to apply mulitple filters to a string
semantic_release.helpers.validate_types_in_sequence(sequence: Sequence, types: type | tuple[type, ...])
-> bool
Validate that all elements in a sequence are of a specific type
Python Semantic Release's Version Bumping Algorithm
Below is a technical description of the algorithm which Python Semantic Release uses to calculate a new
version for a project.
Assumptions
• At runtime, we are in a Git repository with HEAD referring to a commit on some branch of the repository
(i.e. not in detached HEAD state).
• We know in advance whether we want to produce a prerelease or not (based on the configuration and
command-line flags).
• We can parse the tags of the repository into semantic versions, as we are given the format that those
Git tags should follow via configuration, but cannot cherry-pick only tags that apply to commits on
specific branches. We must parse all tags in order to ensure we have parsed any that might apply to
commits in this branch's history.
• If we can identify a commit as a merge-base between our HEAD commit and one or more tags, then that
merge-base should be unique.
• We know ahead of time what prerelease_token to use for prereleases - e.g. rc.
• We know ahead of time whether major changes introduced by commits should cause the new version to
remain on 0.y.z if the project is already on a 0. version - see major_on_zero.
Implementation
1. Parse all the Git tags of the repository into semantic versions, and sort in descending (most recent
first) order according to semver precedence. Ignore any tags which do not correspond to valid
semantic versions according to tag_format.
2. Find the merge-base of HEAD and the latest tag according to the sort above. Call this commit M. If
there are no tags in the repo's history, we set M=HEAD.
3. Find the latest non-prerelease version whose tag references a commit that is an ancestor of M. We do
this via a breadth-first search through the commit lineage, starting against M, and for each tag
checking if the tag corresponds to that commit. We break from the search when we find such a tag. If
no such tag is found, see 4a). Else, suppose that tag corresponds to a commit L - goto 4b).
4.
a. If no commit corresponding to the last non-prerelease version is found, the entire history of the
repository is considered. We parse every commit that is an ancestor of HEAD to determine the type
of change introduced - either major, minor, patch, prerelease_revision or no_release. We store this
levels in a set as we only require the distinct types of change that were introduced.
b. However, if we found a commit L which is the commit against which the last non-prerelease was
tagged, then we parse only the commits from HEAD as far back as L, to understand what changes have
been introduced since the previous non-prerelease. We store these levels - either major, minor,
patch, prerelease_revision, or no_release, in a set, as we only require the distinct types of
change that were introduced.
c. We look for tags that correspond to each commit during this process, to identify the latest
pre-release that was made within HEAD's ancestry.
5. If there have been no changes since the last non-prerelease, or all commits since that release result
in a no_release type according to the commit parser, then we terminate the algorithm.
6. If we have not exited by this point, we know the following information:
• The latest version, by semver precedence, within the whole repository. Call this LV. This might not
be within the ancestry of HEAD.
• The latest version, prerelease or non-prerelease, within the whole repository. Call this LVH. This
might not be within the ancestry of HEAD. This may be the same as LV.
• The latest non-prerelease version within the ancestry of HEAD. Call this LVHF. This may be the same
as LVH.
• The most significant type of change introduced by the commits since the previous full release. Call
this level
• Whether or not we wish to produce a prerelease from this version increment. Call this a boolean
flag, prerelease. (Assumption)
• Whether or not to increment the major digit if a major change is introduced against an existing 0.
version. Call this major_on_zero, a boolean flag. (Assumption)
Using this information, the new version is decided according to the following criteria:
a. If LV has a major digit of 0, major_on_zero is False and level is major, reduce level to minor.
b. If prerelease=True, then
i. Diff LV with LVHF, to understand if the major, minor or patch digits have changed. For
example, diffing 1.2.1 and 1.2.0 is a patch diff, while diffing 2.1.1 and 1.17.2 is a major
diff. Call this DIFF
ii. If DIFF is less semantically significant than level, for example if DIFF=patch and
level=minor, then
1. Increment the digit of LVF corresponding to level, for example the minor digit if
level=minor, setting all less significant digits to zero.
2. Add prerelease_token as a suffix result of 1., together with a prerelease revision number of
1. Return this new version and terminate the algorithm.
Thus if DIFF=patch, level=minor, prerelease=True, prerelease_token="rc", and LVF=1.1.1, then the
version returned by the algorithm is 1.2.0-rc.1.
iii. If DIFF is semantically less significant than or equally significant to level, then this means
that the significance of change introduced by level is already reflected in a prerelease
version that has been created since the last full release. For example, if LVHF=1.1.1,
LV=1.2.0-rc.1 and level=minor.
In this case we:
1. If the prerelease token of LV is different from prerelease_token, take the major, minor and
patch digits of LV and construct a prerelease version using our given prerelease_token and a
prerelease revision of 1. We then return this version and terminate the algorithm.
For example, if LV=1.2.0-rc.1 and prerelease_token=alpha, we return 1.2.0-alpha.1.
2. If the prerelease token of LV is the same as prerelease_token, we increment the revision
number of LV, return this version, and
terminate the algorithm. For example, if LV=1.2.0-rc.1 and prerelease_token=rc, we return
1.2.0-rc.2.
c. If prerelease=False, then
i. If LV is not a prerelease, then we increment the digit of LV corresponding to level, for
example the minor digit if level=minor, setting all less significant digits to zero. We
return the result of this and terminate the algorithm.
ii. If LV is a prerelease, then:
1. Diff LV with LVHF, to understand if the major, minor or patch digits have changed. Call this
DIFF
2. If DIFF is less semantically significant than level, then
i. Increment the digit of LV corresponding to level, for example the minor digit if
level=minor, setting all less significant digits to zero.
ii. Remove the prerelease token and revision number from the result of i., ("Finalize" the
result of i.) return the result and terminate the algorithm.
For example, if LV=1.2.2-alpha.1 and level=minor, we return 1.3.0.
3. If DIFF is semantically less significant than or equally significant to level, then we
finalize LV, return the result and terminate the algorithm.
Complexity
Space:
A list of parsed tags takes O(number of tags) in space. Parsing each commit during the breadth-first
search between merge-base and the latest tag in the ancestry of HEAD takes at worst O(number of commits)
in space to track visited commits. Therefore worst-case space complexity will be linear in the number of
commits in the repo, unless the number of tags significantly exceeds the number of commits (in which case
it will be linear in the number of tags).
Time:
Assuming using regular expression parsing of each tag is a constant-time operation, then the following
steps contribute to the time complexity of the algorithm:
• Parsing each tag - O(number of tags)
• Sorting tags by semver precedence - O(number of tags * log(number of tags))
• Finding the merge-base of HEAD and the latest release tag - O(number of commits) (worst case)
• Parsing each commit and checking each tag against each commit - O(number of commits) + O(number of tags
* number of commits) (worst case)
Overall, assuming that the number of tags is less than or equal to the number of commits in the
repository, this would lead to a worst-case time complexity that's quadratic in the number of commits in
the repo.
CHANGELOG
v9.21.0 (2025-02-23)
✨ Features
• Add package name variant, python-semantic-release, project script, closes #1195 (PR#1199, 1ac97bc)
📖 Documentation
• github-actions: Update example workflow to handle rapid merges (PR#1200, 1a4116a)
v9.20.0 (2025-02-17)
✨ Features
• cmd-version: Enable stamping of tag formatted versions into files, closes #846 (PR#1190, 8906d8e)
• cmd-version: Extend version_variables to stamp versions with @ symbol separator, closes #1156 (PR#1185,
23f69b6)
📖 Documentation
• configuration: Add usage information for tag format version stamping (PR#1190, 8906d8e)
• configuration: Clarify version_variables config description & @ separator usage (PR#1185, 23f69b6)
⚙️ Build System
• deps: Add deprecated~=1.2 for deprecation notices & sphinx documentation (PR#1190, 8906d8e)
v9.19.1 (2025-02-11)
🪲 Bug Fixes
• changelog: Standardize heading format for across all version sections (PR#1182, 81f9e80)
• changelog-md: Standardize heading format for extra release information (PR#1182, 81f9e80)
• changelog-rst: Standardize heading format for extra release information (PR#1182, 81f9e80)
• config: Handle invalid commit_parser type gracefully (PR#1180, 903c8ba)
• release-notes: Standardize heading format for extra release information (PR#1182, 81f9e80)
📖 Documentation
• Fix spelling errors & inaccurate descriptions (55d4a05)
• automatic-releases: Declutter the table of contents for automatic release guides (e8343ee)
• commit-parsing: Update reference to section name of additional release info (PR#1182, 81f9e80)
v9.19.0 (2025-02-10)
✨ Features
• parser-conventional: Add official conventional-commits parser (PR#1177, 27ddf84)
📖 Documentation
• Update references to Angular parser to Conventional Commit Parser (PR#1177, 27ddf84)
💡 ADDITIONAL RELEASE INFORMATION
• parser-conventional: The 'angular' commit parser has been renamed to 'conventional' to match the
official conventional-commits standard for which the 'angular' parser has evolved into. Please update
your configurations to specify 'conventional' as the 'commit_parser' value in place of 'angular'. The
'angular' type will be removed in v11.
v9.18.1 (2025-02-08)
🪲 Bug Fixes
• config: Refactors default token resolution to prevent pre-mature insecure URL error, closes #1074, ‐
#1169 (PR#1173, 37db258)
v9.18.0 (2025-02-06)
✨ Features
• Add create_release_url & format_w_official_vcs_name filters (PR#1161, f853cf0)
• changelog: Add create_pypi_url filter to jinja template render context (PR#1160, 45d49c3)
• changelog: Add additional release info to changeling from commit NOTICE's (PR#1166, 834ce32)
• changelog-md: Add additional release info section to default markdown template, closes #223 (PR#1166, ‐
834ce32)
• changelog-rst: Add additional release info section to default ReStructuredText template, closes #223 (‐
PR#1166, 834ce32)
• commit-parser: Enable parsers to identify additional release notices from commit msgs (PR#1166, ‐
834ce32)
• parser-angular: Add a ignore_merge_commits option to discard parsing merge commits (PR#1164, 463e43b)
• parser-angular: Add functionality to parse out NOTICE: prefixed statements in commits, closes #223 (‐
PR#1166, 834ce32)
• parser-emoji: Add a ignore_merge_commits option to discard parsing merge commits (PR#1164, 463e43b)
• parser-emoji: Add functionality to parse out NOTICE: prefixed statements in commits, closes #223 (‐
PR#1166, 834ce32)
• parsers: Add option ignore_merge_commits to discard parsing merge commits (PR#1164, 463e43b)
• release-notes: Add license information to default release notes template, closes #228 (PR#1167, ‐
41172c1)
• vcs-bitbucket: Add format_w_official_vcs_name filter function (PR#1161, f853cf0)
• vcs-gitea: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
• vcs-github: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
• vcs-gitlab: Add create_release_url & format_w_official_vcs_name filter functions (PR#1161, f853cf0)
🪲 Bug Fixes
• Refactor parsing compatibility function to support older custom parsers (PR#1165, cf340c5)
• changelog: Fix parsing compatibility w/ custom parsers, closes #1162 (PR#1165, cf340c5)
• changelog-templates: Adjust default templates to avoid empty version sections (PR#1164, 463e43b)
• parser-angular: Adjust parser to prevent empty message extractions (PR#1166, 834ce32)
• parser-emoji: Adjust parser to prevent empty message extractions (PR#1166, 834ce32)
• version: Fix parsing compatibility w/ custom parsers, closes #1162 (PR#1165, cf340c5)
📖 Documentation
• changelog: Add formatted changelog into hosted documentation (PR#1155, 2f18a6d)
• changelog-templates: Add description for new create_pypi_url filter function (PR#1160, 45d49c3)
• changelog-templates: Add details about license specification in the release notes (PR#1167, 41172c1)
• changelog-templates: Define create_release_url & format_w_official_vcs_name filters (PR#1161, f853cf0)
• changelog-templates: Document special separate sections of commit descriptions (ebb4c67)
• commit-parsing: Document new release notice footer detection feature of built-in parsers (cd14e92)
v9.17.0 (2025-01-26)
✨ Features
• changelog: Add sort_numerically filter function to template environment (PR#1146, 7792388)
• changelog: Parse squashed commits individually (PR#1112, cf785ca)
• config: Extend support of remote urls aliased using git insteadOf configurations, closes #1150 (‐
PR#1151, 4045037)
• parsers: Parse squashed commits individually (PR#1112, cf785ca)
• parser-angular: Apply PR/MR numbers to all parsed commits from a squash merge (PR#1112, cf785ca)
• parser-angular: Upgrade angular parser to parse squashed commits individually, closes #1085 (PR#1112, ‐
cf785ca)
• parser-emoji: Add functionality to interpret scopes from gitmoji commit messages (PR#1112, cf785ca)
• parser-emoji: Upgrade emoji parser to parse squashed commits individually (PR#1112, cf785ca)
• version: Parse squashed commits individually (PR#1112, cf785ca)
🪲 Bug Fixes
• github-action: Disable writing python bytecode in action execution (PR#1152, 315ae21)
⚡ Performance Improvements
• logging: Remove irrelevant debug logging statements (PR#1147, f1ef4ec)
📖 Documentation
• changelog-templates: Add description for new sort_numerically filter function (PR#1146, 7792388)
• commit-parsing: Add description for squash commit evaluation option of default parsers (PR#1112, ‐
cf785ca)
• configuration: Update the commit_parser_options setting description (PR#1112, cf785ca)
v9.16.1 (2025-01-12)
🪲 Bug Fixes
• parser-custom: Handle relative parent directory paths to module file better (PR#1142, c4056fc)
📖 Documentation
• github-actions: Update PSR versions in github workflow examples (PR#1140, 9bdd626)
v9.16.0 (2025-01-12)
✨ Features
• config: Expand dynamic parser import to handle a filepath to module (PR#1135, 0418fd8)
🪲 Bug Fixes
• changelog: Fixes PSR release commit exclusions for customized commit messages (PR#1139, f9a2078)
• cmd-version: Fixes --print-tag result to match configured tag format (PR#1134, a990aa7)
• cmd-version: Fixes tag format on default version when force bump for initial release, closes #1137 (‐
PR#1138, 007fd00)
• config-changelog: Validate changelog.exclude_commit_patterns on config load (PR#1139, f9a2078)
📖 Documentation
• commit-parsing: Add the new custom parser import spec description for direct path imports, closes #687
(PR#1135, 0418fd8)
• configuration: Adjust commit_parser option definition for direct path imports (PR#1135, 0418fd8)
v9.15.2 (2024-12-16)
🪲 Bug Fixes
• changelog: Ensures user rendered files are trimmed to end with a single newline (PR#1118, 6dfbbb0)
• cli: Add error message of how to gather full error output (PR#1116, ba85532)
• cmd-version: Enable maintenance prereleases (PR#864, b88108e)
• cmd-version: Fix handling of multiple prerelease token variants & git flow merges (PR#1120, 8784b9a)
• cmd-version: Fix version determination algorithm to capture commits across merged branches (PR#1120, ‐
8784b9a)
• cmd-version: Forces tag timestamp to be same time as release commit (PR#1117, 7898b11)
• cmd-version: Handle multiple prerelease token variants properly, closes #789 (PR#1120, 8784b9a)
• config: Ensure default config loads on network mounted windows environments, closes #1123 (PR#1124, ‐
a64cbc9)
• version: Remove some excessive log msgs from debug to silly level (PR#1120, 8784b9a)
• version-bump: Increment based on current commit's history only, closes #861 (PR#864, b88108e)
⚡ Performance Improvements
• cmd-version: Refactor version determination algorithm for accuracy & speed (PR#1120, 8784b9a)
v9.15.1 (2024-12-03)
🪲 Bug Fixes
• changelog-md: Fix commit sort of breaking descriptions section (75b342e)
• parser-angular: Ensure issues are sorted by numeric value rather than text sorted (3858add)
• parser-emoji: Ensure issues are sorted by numeric value rather than text sorted (7b8d2d9)
v9.15.0 (2024-12-02)
✨ Features
• changelog-md: Add a breaking changes section to default Markdown template, closes #244 (PR#1110, ‐
4fde30e)
• changelog-md: Alphabetize breaking change descriptions in markdown changelog template (PR#1110, ‐
4fde30e)
• changelog-md: Alphabetize commit summaries & scopes in markdown changelog template (PR#1111, 8327068)
• changelog-rst: Add a breaking changes section to default reStructuredText template, closes #244 (‐
PR#1110, 4fde30e)
• changelog-rst: Alphabetize breaking change descriptions in ReStructuredText template (PR#1110, 4fde30e)
• changelog-rst: Alphabetize commit summaries & scopes in ReStructuredText template (PR#1111, 8327068)
• commit-parser: Enable parsers to flag commit to be ignored for changelog, closes #778 (PR#1108, ‐
0cc668c)
• default-changelog: Add a separate formatted breaking changes section, closes #244 (PR#1110, 4fde30e)
• default-changelog: Alphabetize commit summaries & scopes in change sections (PR#1111, 8327068)
• parsers: Add other_allowed_tags option for commit parser options (PR#1109, f90b8dc)
• parsers: Enable parsers to identify linked issues on a commit (PR#1109, f90b8dc)
• parser-angular: Automatically parse angular issue footers from commit messages (PR#1109, f90b8dc)
• parser-custom: Enable custom parsers to identify linked issues on a commit (PR#1109, f90b8dc)
• parser-emoji: Parse issue reference footers from commit messages (PR#1109, f90b8dc)
• release-notes: Add tag comparison link to release notes when supported (PR#1107, 9073344)
🪲 Bug Fixes
• cmd-version: Ensure release utilizes a timezone aware datetime (ca817ed)
• default-changelog: Alphabetically sort commit descriptions in version type sections (bdaaf5a)
• util: Prevent git footers from being collapsed during parse (PR#1109, f90b8dc)
📖 Documentation
• api-parsers: Add option documentation to parser options (PR#1109, f90b8dc)
• changelog-templates: Update examples using new commit.linked_issues attribute (PR#1109, f90b8dc)
• commit-parsing: Improve & expand commit parsing w/ parser descriptions (PR#1109, f90b8dc)
v9.14.0 (2024-11-11)
✨ Features
• changelog: Add md to rst conversion for markdown inline links (cb2af1f)
• changelog: Define first release w/o change descriptions for default MD template (fa89dec)
• changelog: Define first release w/o change descriptions for default RST template (e30c94b)
• changelog: Prefix scopes on commit descriptions in default template (PR#1093, 560fd2c)
• changelog-md: Add markdown inline link format macro (c6d8211)
• changelog-md: Prefix scopes on commit descriptions in Markdown changelog template (PR#1093, 560fd2c)
• changelog-rst: Prefix scopes on commit descriptions in ReStructuredText template (PR#1093, 560fd2c)
• configuration: Add changelog.default_templates.mask_initial_release option (595a70b)
• context: Add mask_initial_release setting to changelog context (6f2ee39)
• release-notes: Define first release w/o change descriptions in default template (83167a3)
🪲 Bug Fixes
• release-notes: Override default word-wrap to non-wrap for in default template (99ab99b)
📖 Documentation
• changelog-templates: Document new mask_initial_release changelog context variable (f294957)
• configuration: Document new mask_initial_release option usage & effect (3cabcdc)
• homepage: Fix reference to new ci workflow for test status badge (6760069)
v9.13.0 (2024-11-10)
✨ Features
• changelog: Add PR/MR url linking to default Markdown changelog, closes #924, #953 (cd8d131)
• changelog: Add PR/MR url linking to default reStructuredText template, closes #924, #953 (5f018d6)
• parsed-commit: Add linked merge requests list to the ParsedCommit object (9a91062)
• parser-angular: Automatically parse PR/MR numbers from subject lines in commits (2ac798f)
• parser-emoji: Automatically parse PR/MR numbers from subject lines in commits (bca9909)
• parser-scipy: Automatically parse PR/MR numbers from subject lines in commits (2b3f738)
🪲 Bug Fixes
• changelog-rst: Ignore unknown parsed commit types in default RST changelog (77609b1)
• parser-angular: Drop the breaking category but still maintain a major level bump (f1ffa54)
• parsers: Improve reliability of descriptions after reverse word-wrap (436374b)
⚡ Performance Improvements
• parser-angular: Simplify commit parsing type pre-calculation (a86a28c)
• parser-emoji: Increase speed of commit parsing (2c9c468)
• parser-scipy: Increase speed & decrease complexity of commit parsing (2b661ed)
📖 Documentation
• changelog-templates: Add linked_merge_request field to examples (d4376bc)
• changelog-templates: Fix api class reference links (7a5bdf2)
• commit-parsing: Add linked_merge_request field to Parsed Commit definition (ca61889)
v9.12.2 (2024-11-07)
🪲 Bug Fixes
• bitbucket: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
• cli: Gracefully capture all exceptions unless in very verbose debug mode (PR#1088, 13ca44f)
• gitea: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
• gitea: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
• github: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
• github: Fix pull_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
• gitlab: Fix issue_url filter to ignore an issue prefix gracefully (PR#1089, 275ec88)
• gitlab: Fix merge_request_url filter to ignore an PR prefix gracefully (PR#1089, 275ec88)
• hvcs: Add flexibility to issue & MR/PR url jinja filters (PR#1089, 275ec88)
📖 Documentation
• changelog-templates: Update descriptions of issue & MR/PR url jinja filters (PR#1089, 275ec88)
v9.12.1 (2024-11-06)
🪲 Bug Fixes
• changelog: Fix raw-inline pattern replacement in convert_md_to_rst filter (2dc70a6)
• cmd-version: Fix --as-prerelease when no commit change from last full release (PR#1076, 3b7b772)
• release-notes: Add context variable shorthand ctx like docs claim & changelog has (d618d83)
📖 Documentation
• contributing: Update local testing instructions (74f03d4)
v9.12.0 (2024-10-18)
✨ Features
• changelog: Add autofit_text_width filter to template environment (PR#1062, 83e4b86)
🪲 Bug Fixes
• changelog: Ignore commit exclusion when a commit causes a version bump (e8f886e)
• parser-angular: Change Fixes commit type heading to Bug Fixes (PR#1064, 09e3a4d)
• parser-emoji: Enable the default bump level option (bc27995)
📖 Documentation
• changelog-templates: Add definition & usage of autofit_text_width template filter (PR#1062, 83e4b86)
• commit-parsers: Add deprecation message for the tag parser (af94540)
• configuration: Add deprecation message for the tag parser (a83b7e4)
v9.11.1 (2024-10-15)
🪲 Bug Fixes
• changelog: Prevent custom template errors when components are in hidden folders (PR#1060, a7614b0)
v9.11.0 (2024-10-12)
✨ Features
• changelog: Add convert_md_to_rst filter to changelog environment (PR#1055, c2e8831)
• changelog: Add default changelog in re-structured text format, closes #399 (PR#1055, c2e8831)
• changelog: Add default changelog template in reStructuredText format (PR#1055, c2e8831)
• config: Enable default changelog.insertion_flag based on output format (PR#1055, c2e8831)
• config: Enable target changelog filename to trigger RST output format, closes #399 (PR#1055, c2e8831)
🪲 Bug Fixes
• changelog: Correct spacing for default markdown template during updates (PR#1055, c2e8831)
📖 Documentation
• changelog: Clarify the convert_md_to_rst filter added to the template environment (PR#1055, c2e8831)
• changelog: Increase detail about configuration options of default changelog creation (PR#1055, c2e8831)
• configuration: Update changelog_file with deprecation notice of setting relocation (PR#1055, c2e8831)
• configuration: Update output_format description for reStructuredText support (PR#1055, c2e8831)
• configuration: Update details of insertion_flag's dynamic defaults with rst (PR#1055, c2e8831)
v9.10.1 (2024-10-10)
🪲 Bug Fixes
• config: Handle branch match regex errors gracefully (PR#1054, 4d12251)
v9.10.0 (2024-10-08)
✨ Features
• changelog: Add changelog_insertion_flag to changelog template context (PR#1045, c18c245)
• changelog: Add changelog_mode to changelog template context (PR#1045, c18c245)
• changelog: Add prev_changelog_file to changelog template context (PR#1045, c18c245)
• changelog: Add read_file function to changelog template context (PR#1045, c18c245)
• changelog: Add shorthand ctx variable to changelog template env (PR#1045, c18c245)
• changelog: Modify changelog template to support changelog updates, closes #858 (PR#1045, c18c245)
• config: Add changelog.default_templates.output_format config option (PR#1045, c18c245)
• config: Add changelog.insertion_flag as configuration option (PR#1045, c18c245)
• config: Add changelog.mode as configuration option (PR#1045, c18c245)
• github-actions: Add an action build directive to toggle the --skip-build option (PR#1044, 26597e2)
🪲 Bug Fixes
• changelog: Adjust angular heading names for readability (PR#1045, c18c245)
• changelog: Ensure changelog templates can handle complex directory includes (PR#1045, c18c245)
• changelog: Only render user templates when files exist (PR#1045, c18c245)
• config: Prevent jinja from autoescaping markdown content by default (PR#1045, c18c245)
📖 Documentation
• changelog-templates: Improve detail & describe new changelog.mode="update" (PR#1045, c18c245)
• commands: Update definition of the version commands --skip-build option (PR#1044, 26597e2)
• configuration: Add changelog.mode and changelog.insertion_flag config definitions (PR#1045, c18c245)
• configuration: Define the new changelog.default_templates.output_format option (PR#1045, c18c245)
• configuration: Mark version of configuration setting introduction (PR#1045, c18c245)
• configuration: Standardize all true/false to lowercase ensuring toml-compatibility (PR#1045, c18c245)
• configuration: Update changelog.environment.autoescape default to false to match code (PR#1045, ‐
c18c245)
• github-actions: Add description of the build input directive (PR#1044, 26597e2)
• github-actions: Update primary example with workflow sha controlled pipeline (14f04df)
• homepage: Update custom changelog reference (PR#1045, c18c245)
v9.9.0 (2024-09-28)
✨ Features
• github-actions: Add is_prerelease output to the version action (PR#1038, 6a5d35d)
📖 Documentation
• automatic-releases: Drop extraneous github push configuration (PR#1011, 2135c68)
• github-actions: Add configuration & description of publish action (PR#1011, 2135c68)
• github-actions: Add description of new is_prerelease output for version action (PR#1038, 6a5d35d)
• github-actions: Clarify & consolidate GitHub Actions usage docs, closes #907 (PR#1011, 2135c68)
• github-actions: Expand descriptions & clarity of actions configs (PR#1011, 2135c68)
• github-actions: Revert removal of namespace prefix from examples (PR#1011, 2135c68)
• homepage: Remove link to old github config & update token scope config (PR#1011, 2135c68)
v9.8.9 (2024-09-27)
🪲 Bug Fixes
• version-cmd: Ensure version_variables do not match partial variable names (PR#1028, 156915c)
• version-cmd: Improve version_variables flexibility w/ quotes (ie. json, yaml, etc) (PR#1028, 156915c)
• version-cmd: Increase version_variable flexibility with quotations (ie. json, yaml, etc), closes #601,
#706, #962, #1026 (PR#1028, 156915c)
📖 Documentation
• Update docstrings to resolve sphinx failures, closes #1029 (PR#1030, d84efc7)
• configuration: Add clarity to version_variables usage & limitations (PR#1028, 156915c)
• homepage: Re-structure homepage to be separate from project readme (PR#1032, 2307ed2)
• README: Simplify README to point at official docs (PR#1032, 2307ed2)
v9.8.8 (2024-09-01)
🪲 Bug Fixes
• config: Fix path traversal detection for windows compatibility, closes #994 (PR#1014, 16e6daa)
📖 Documentation
• configuration: Update build_command env table for windows to use all capital vars (0e8451c)
• github-actions: Update version in examples to latest version (3c894ea)
v9.8.7 (2024-08-20)
🪲 Bug Fixes
• Provide context.history global in release notes templates (PR#1005, 5bd91b4)
• release-notes: Fix noop-changelog to print raw release notes (PR#1005, 5bd91b4)
• release-notes: Provide context.history global in release note templates, closes #984 (PR#1005, 5bd91b4)
📖 Documentation
• Use pinned version for GHA examples (PR#1004, 5fdf761)
• changelog: Clarify description of the default changelog generation process (399fa65)
• configuration: Clarify changelog_file vs template_dir option usage, closes #983 (a7199c8)
• configuration: Fix build_command_env table rendering (PR#996, a5eff0b)
• github-actions: Adjust formatting & version warning in code snippets (PR#1004, 5fdf761)
• github-actions: Use pinned version for GHA examples, closes #1003 (PR#1004, 5fdf761)
v9.8.6 (2024-07-20)
🪲 Bug Fixes
• version-cmd: Resolve build command execution in powershell (PR#980, 32c8e70)
📖 Documentation
• configuration: Correct GHA parameter name for commit email (PR#981, ce9ffdb)
v9.8.5 (2024-07-06)
🪲 Bug Fixes
• Enable --print-last-released* when in detached head or non-release branch (PR#926, 782c0a6)
• changelog: Resolve commit ordering issue when dates are similar (PR#972, bfda159)
• version-cmd: Drop branch restriction for --print-last-released* opts, closes #900 (PR#926, 782c0a6)
⚡ Performance Improvements
• Improve git history processing for changelog generation (PR#972, bfda159)
• changelog: Improve git history parser changelog generation (PR#972, bfda159)
v9.8.4 (2024-07-04)
🪲 Bug Fixes
• changelog-cmd: Remove usage strings when error occurred, closes #810 (348a51d)
• changelog-cmd: Render default changelog when user template directory exist but is empty (bded8de)
• config: Prevent path traversal manipulation of target changelog location (43e35d0)
• config: Prevent path traversal manipulation of target changelog location (3eb3dba)
• publish-cmd: Prevent error when provided tag does not exist locally (16afbbb)
• publish-cmd: Remove usage strings when error occurred, closes #810 (afbb187)
• version-cmd: Remove usage strings when error occurred, closes #810 (a7c17c7)
v9.8.3 (2024-06-18)
🪲 Bug Fixes
• parser: Strip DOS carriage-returns in commits, closes #955 (PR#956, 0b005df)
v9.8.2 (2024-06-17)
🪲 Bug Fixes
• templates: Suppress extra newlines in default changelog (PR#954, 7b0079b)
v9.8.1 (2024-06-05)
🪲 Bug Fixes
• Improve build cmd env on windows (PR#942, d911fae)
• version-cmd: Pass windows specific env vars to build cmd when on windows (PR#942, d911fae)
📖 Documentation
• configuration: Define windows specific env vars for build cmd (PR#942, d911fae)
v9.8.0 (2024-05-27)
✨ Features
• Extend gitlab to edit a previous release if exists (PR#934, 23e02b9)
• gha: Configure ssh signed tags in GitHub Action, closes #936 (PR#937, dfb76b9)
• hvcs-gitlab: Enable gitlab to edit a previous release if found (PR#934, 23e02b9)
• version-cmd: Add toggle of --no-verify option to git commit (PR#927, 1de6f78)
🪲 Bug Fixes
• gitlab: Adjust release name to mirror other hvcs release names (PR#934, 23e02b9)
• hvcs-gitlab: Add tag message to release creation (PR#934, 23e02b9)
📖 Documentation
• configuration: Add no_git_verify description to the configuration page (PR#927, 1de6f78)
• migration-v8: Update version references in migration instructions (PR#938, d6ba16a)
v9.7.3 (2024-05-15)
🪲 Bug Fixes
• Enabled prerelease-token parameter in github action (PR#929, 1bb26b0)
v9.7.2 (2024-05-13)
🪲 Bug Fixes
• Enable user configuration of build_command env vars (PR#925, 6b5b271)
• version: Enable user config of build_command env variables, closes #922 (PR#925, 6b5b271)
📖 Documentation
• configuration: Clarify TOC & alphabetize configuration descriptions (19add16)
• configuration: Clarify TOC & standardize heading links (3a41995)
• configuration: Document build_command_env configuration option (PR#925, 6b5b271)
• CONTRIBUTING: Update build command definition for developers (PR#921, b573c4d)
v9.7.1 (2024-05-07)
🪲 Bug Fixes
• gha: Fix missing git_committer_* definition in action, closes #918 (PR#919, ccef9d8)
v9.7.0 (2024-05-06)
✨ Features
• version-cmd: Pass NEW_VERSION & useful env vars to build command (ee6b246)
🪲 Bug Fixes
• gha: Add missing tag option to GitHub Action definition, closes #906 (PR#908, 6b24288)
• gha: Correct use of prerelease option for GitHub Action (PR#914, 85e27b7)
📖 Documentation
• configuration: Add description of build command available env variables (c882dc6)
• gha: Update GitHub Actions doc with all available options (PR#914, 85e27b7)
⚙️ Build System
• deps: Bump GitHub Action container to use python3.12, closes #801 (PR#914, 85e27b7)
v9.6.0 (2024-04-29)
✨ Features
• Changelog filters are specialized per vcs type (PR#890, 76ed593)
• changelog: Changelog filters are hvcs focused (PR#890, 76ed593)
• changelog-context: Add flag to jinja env for which hvcs is available (PR#890, 76ed593)
• changelog-gitea: Add issue url filter to changelog context (PR#890, 76ed593)
• changelog-github: Add issue url filter to changelog context (PR#890, 76ed593)
• version-cmd: Add --as-prerelease option to force the next version to be a prerelease, closes #639 (‐
PR#647, 2acb5ac)
🪲 Bug Fixes
• Correct version --prerelease use & enable --as-prerelease (PR#647, 2acb5ac)
• github: Correct changelog filter for pull request urls (PR#890, 76ed593)
• parser-custom: Gracefully handle custom parser import errors (67f6038)
• version-cmd: Correct --prerelease use, closes #639 (PR#647, 2acb5ac)
📖 Documentation
• changelog-context: Explain new hvcs specific context filters (PR#890, 76ed593)
• commands: Update version command options definition about prereleases (PR#647, 2acb5ac)
v9.5.0 (2024-04-23)
✨ Features
• Extend support to on-prem GitHub Enterprise Server (PR#896, 4fcb737)
• github: Extend support to on-prem GitHub Enterprise Server, closes #895 (PR#896, 4fcb737)
v9.4.2 (2024-04-14)
🪲 Bug Fixes
• bitbucket: Allow insecure http connections if configured (PR#886, db13438)
• bitbucket: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
• config: Add flag to allow insecure connections (PR#886, db13438)
• gitea: Allow insecure http connections if configured (PR#886, db13438)
• gitea: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
• github: Allow insecure http connections if configured (PR#886, db13438)
• github: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
• gitlab: Allow insecure http connections if configured (PR#886, db13438)
• gitlab: Correct url parsing & prevent double url schemes (PR#676, 5cfdb24)
• hvcs: Allow insecure http connections if configured (PR#886, db13438)
• hvcs: Prevent double protocol scheme urls in changelogs (PR#676, 5cfdb24)
• version-cmd: Handle HTTP exceptions more gracefully (PR#886, db13438)
📖 Documentation
• configuration: Update remote settings section with missing values, closes #868 (PR#886, db13438)
⚙️ Build System
• deps: Update rich requirement from ~=12.5 to ~=13.0, closes #888 (PR#877, 4a22a8c)
v9.4.1 (2024-04-06)
🪲 Bug Fixes
• gh-actions-output: Fixed trailing newline to match GITHUB_OUTPUT format (PR#885, 2c7b6ec)
• gh-actions-output: Fixed trailing newline to match GITHUB_OUTPUT format, closes #884 (PR#885, 2c7b6ec)
v9.4.0 (2024-03-31)
✨ Features
• gitea: Derives gitea api domain from base domain when unspecified (PR#675, 2ee3f8a)
v9.3.1 (2024-03-24)
🪲 Bug Fixes
• algorithm: Handle merge-base errors gracefully, closes #724 (4c998b7)
• cli-version: Change implementation to only push the tag we generated, closes #803 (8a9da4f)
⚡ Performance Improvements
• algorithm: Simplify logs & use lookup when searching for commit & tag match (3690b95)
v9.3.0 (2024-03-21)
✨ Features
• cmd-version: Changelog available to bundle (PR#779, 37fdb28)
• cmd-version: Create changelog prior to build enabling doc bundling (PR#779, 37fdb28)
v9.2.2 (2024-03-19)
🪲 Bug Fixes
• cli: Enable subcommand help even if config is invalid, closes #840 (91d221a)
v9.2.1 (2024-03-19)
🪲 Bug Fixes
• parse-git-url: Handle urls with url-safe special characters (27cd93a)
v9.2.0 (2024-03-18)
✨ Features
• version: Add new version print flags to display the last released version and tag (814240c)
• version-config: Add option to disable 0.x.x versions (dedb3b7)
🪲 Bug Fixes
• changelog: Make sure default templates render ending in 1 newline (0b4a45e)
• changelog-generation: Fix incorrect release timezone determination (f802446)
📖 Documentation
• configuration: Add description of allow-zero-version configuration option (4028f83)
• configuration: Clarify the major_on_zero configuration option (f7753cd)
⚙️ Build System
• deps: Add click-option-group for grouping exclusive flags (bd892b8)
v9.1.1 (2024-02-25)
🪲 Bug Fixes
• parse_git_url: Fix bad url with dash (1c25b8e)
v9.1.0 (2024-02-14)
✨ Features
• Add bitbucket hvcs (bbbbfeb)
🪲 Bug Fixes
• Remove unofficial environment variables (a5168e4)
📖 Documentation
• Add bitbucket authentication (b78a387)
• Add bitbucket to token table (56f146d)
• Fix typo (b240e12)
⚙️ Build System
• deps: Bump minimum required tomlkit to >=0.11.0, closes #834 (291aace)
v9.0.3 (2024-02-08)
🪲 Bug Fixes
• algorithm: Correct bfs to not abort on previously visited node (02df305)
⚡ Performance Improvements
• algorithm: Refactor bfs search to use queue rather than recursion (8b742d3)
v9.0.2 (2024-02-08)
🪲 Bug Fixes
• util: Properly parse windows line-endings in commit messages, closes #820 (70193ba)
📖 Documentation
• Remove duplicate note in configuration.rst (PR#807, fb6f243)
v9.0.1 (2024-02-06)
🪲 Bug Fixes
• config: Set commit parser opt defaults based on parser choice (PR#782, 9c594fb)
v9.0.0 (2024-02-06)
♻️ Refactoring
• Drop support for Python 3.7 (PR#828, ad086f5)
💥 BREAKING CHANGES
• Removed Python 3.7 specific control flows and made more modern implementations the default control flow
without a bypass or workaround. Will break on Python 3.7 now. If you require Python 3.7, you should
lock your major version at v8. Since we only have enough manpower to maintain the latest major release,
unfortunately there will not be any more updates to v8.
• We decided to remove support for Python 3.7 because it has been officially deprecated by the Python
Foundation over a year ago and our codebase is starting to have limitations and custom implementations
just to maintain support for 3.7.
v8.7.2 (2024-01-03)
🪲 Bug Fixes
• lint: Correct linter errors (c9556b0)
v8.7.1 (2024-01-03)
🪲 Bug Fixes
• cli-generate-config: Ensure configuration types are always toml parsable (PR#785, 758e649)
📖 Documentation
• Add note on default envvar behavior (PR#780, 0b07cae)
• configuration: Change defaults definition of token default to table (PR#786, df1df0d)
• contributing: Add docs-build, testing conf, & build instructions (PR#787, 011b072)
v8.7.0 (2023-12-22)
✨ Features
• config: Enable default environment token per hvcs (PR#774, 26528eb)
v8.6.0 (2023-12-22)
✨ Features
• utils: Expand parsable valid git remote url formats (PR#771, cf75f23)
📖 Documentation
• Minor correction to commit-parsing documentation (PR#777, 245e878)
v8.5.2 (2023-12-19)
🪲 Bug Fixes
• cli: Gracefully output configuration validation errors (PR#772, e8c9d51)
v8.5.1 (2023-12-12)
🪲 Bug Fixes
• cmd-version: Handle committing of git-ignored file gracefully (PR#764, ea89fa7)
• config: Cleanly handle repository in detached HEAD state (PR#765, ac4f9aa)
• config: Gracefully fail when repo is in a detached HEAD state (PR#765, ac4f9aa)
• version: Only commit non git-ignored files during version commit (PR#764, ea89fa7)
📖 Documentation
• configuration: Adjust wording and improve clarity (PR#766, 6b2fc8c)
• configuration: Fix typo in text (PR#766, 6b2fc8c)
v8.5.0 (2023-12-07)
✨ Features
• Allow template directories to contain a '.' at the top-level (PR#762, 07b232a)
v8.4.0 (2023-12-07)
✨ Features
• cmd-version: Add --tag/--no-tag option to version command (PR#752, de6b9ad)
• version: Add --no-tag option to turn off tag creation (PR#752, de6b9ad)
🪲 Bug Fixes
• version: Separate push tags from commit push when not committing changes (PR#752, de6b9ad)
📖 Documentation
• commands: Update version subcommand options (PR#752, de6b9ad)
• migration: Fix comments about publish command (PR#747, 90380d7)
v8.3.0 (2023-10-23)
✨ Features
• action: Use composite action for semantic release (PR#692, 4648d87)
v8.2.0 (2023-10-23)
✨ Features
• Allow user customization of release notes template (PR#736, 94a1311)
📖 Documentation
• Add PYTHONPATH mention for commit parser (3284258)
v8.1.2 (2023-10-13)
🪲 Bug Fixes
• Correct lint errors (a13a6c3)
• Error when running build command on windows systems (PR#732, 2553657)
v8.1.1 (2023-09-19)
🪲 Bug Fixes
• Attribute error when logging non-strings (PR#711, 75e6e48)
v8.1.0 (2023-09-19)
✨ Features
• Upgrade pydantic to v2 (PR#714, 5a5c5d0)
📖 Documentation
• Fix typos (PR#708, 2698b0e)
• Update project urls (PR#715, 5fd5485)
v8.0.8 (2023-08-26)
🪲 Bug Fixes
• Dynamic_import() import path split (PR#686, 1007a06)
v8.0.7 (2023-08-16)
🪲 Bug Fixes
• Use correct upload url for github (PR#661, 8a515ca)
v8.0.6 (2023-08-13)
🪲 Bug Fixes
• publish: Improve error message when no tags found (PR#683, bdc06ea)
v8.0.5 (2023-08-10)
🪲 Bug Fixes
• Don't warn about vcs token if ignore_token_for_push is true. (PR#670, f1a54a6)
📖 Documentation
• password should be token. (PR#670, f1a54a6)
• Fix typo missing 's' in version_variable[s] in configuration.rst (PR#668, 879186a)
v8.0.4 (2023-07-26)
🪲 Bug Fixes
• changelog: Use version as semver tag by default (PR#653, 5984c77)
📖 Documentation
• Add Python 3.11 to classifiers in metadata (PR#651, 5a32a24)
• Clarify usage of assets config option (PR#655, efa2b30)
v8.0.3 (2023-07-21)
🪲 Bug Fixes
• Skip non-parsable versions when calculating next version (PR#649, 88f25ea)
v8.0.2 (2023-07-18)
🪲 Bug Fixes
• Handle missing configuration (PR#644, f15753c)
📖 Documentation
• Better description for tag_format usage (2129b72)
• Clarify v8 breaking changes in GitHub action inputs (PR#643, cda050c)
• Correct version_toml example in migrating_from_v7.rst (PR#641, 325d5e0)
v8.0.1 (2023-07-17)
🪲 Bug Fixes
• Invalid version in Git history should not cause a release failure (PR#632, 254430b)
📖 Documentation
• Reduce readthedocs formats and add entries to migration from v7 guide (9b6ddfe)
• migration: Fix hyperlink (PR#631, 5fbd52d)
v8.0.0 (2023-07-16)
✨ Features
• publish-cmd: Add --post-to-release-tag option to control where to publish (PR#619, ec30564)
• Make it easier to access commit messages in ParsedCommits (PR#619, ec30564)
• Remove publication of dists/ to artifact repository (PR#619, ec30564)
• Rename 'upload' configuration section to 'publish' (PR#619, ec30564)
• github-action: Add GitHub Actions output variables (PR#619, ec30564)
• version-cmd: Add --skip-build option (PR#619, ec30564)
• version-cmd Add --strict version mode (PR#619, ec30564)
🪲 Bug Fixes
• Add logging for token auth, use token for push (PR#619, ec30564)
• Caching for repo owner and name (PR#619, ec30564)
• Correct assets type in configuration (PR#619, ec30564)
• Correct assets type-annotation for RuntimeContext (PR#619, ec30564)
• Correct Dockerfile CLI command and GHA fetch (PR#619, ec30564)
• Correct handling of build commands (PR#619, ec30564)
• Correct logic for generating release notes (PR#619, ec30564)
• Create_or_update_release for Gitlab hvcs (PR#619, ec30564)
• Make additional attributes available for template authors (PR#619, ec30564)
• Only call Github Action output callback once defaults are set (PR#619, ec30564)
• Remove commit amending behavior (PR#619, ec30564)
• Resolve branch checkout logic in GHA (PR#619, ec30564)
• Resolve bug in changelog logic, enable upload to pypi (PR#619, ec30564)
• Resolve loss of tag_format configuration (PR#619, ec30564)
• github-action: Pin Debian version in Dockerfile (PR#619, ec30564)
• github-action: Correct input parsing (PR#619, ec30564)
• github-action: Mark container fs as safe for git to operate on (PR#619, ec30564)
• github-action: Quotation for git config command (PR#619, ec30564)
• github-action: Remove default for 'force' (PR#619, ec30564)
📖 Documentation
• Convert to Furo theme (PR#619, ec30564)
• Fix typo (PR#619, ec30564)
• Remove reference to dist publication (PR#619, ec30564)
• Update docs with additional required permissions (PR#619, ec30564)
• changelog-templates: fix typo (PR#619, ec30564)
♻️ Refactoring
• Remove verify-ci command (PR#619, ec30564)
💥 BREAKING CHANGES
• numerous breaking changes, see Migrating from Python Semantic Release v7 for more information
v7.34.6 (2023-06-17)
🪲 Bug Fixes
• Relax invoke dependency constraint (18ea200)
v7.34.5 (2023-06-17)
🪲 Bug Fixes
• Consider empty commits (PR#608, 6f2e890)
v7.34.4 (2023-06-15)
🪲 Bug Fixes
• Docker build fails installing git (PR#605, 9e3eb97)
v7.34.3 (2023-06-01)
🪲 Bug Fixes
• Generate markdown linter compliant changelog headers & lists (PR#597, cc87400)
v7.34.2 (2023-05-29)
🪲 Bug Fixes
• Open all files with explicit utf-8 encoding (PR#596, cb71f35)
v7.34.1 (2023-05-28)
🪲 Bug Fixes
• Generate markdown linter compliant changelog headers & lists (PR#594, 9d9d403)
v7.34.0 (2023-05-28)
✨ Features
• Add option to only parse commits for current working directory (PR#509, cdf8116)
v7.33.5 (2023-05-19)
🪲 Bug Fixes
• Update docs and default config for gitmoji changes (PR#590, 192da6e)
• Update sphinx dep (PR#590, 192da6e)
📖 Documentation
• Update broken badge and add links (PR#591, 0c23447)
v7.33.4 (2023-05-14)
🪲 Bug Fixes
• If prerelease, publish prerelease (PR#587, 927da9f)
v7.33.3 (2023-04-24)
🪲 Bug Fixes
• Trim emojis from config (PR#583, 02902f7)
• Update Gitmojis according to official node module (PR#582, 806fcfa)
📖 Documentation
• Grammar in docs/troubleshooting.rst (PR#557, bbe754a)
• Spelling and grammar in travis.rst (PR#556, 3a76e9d)
• Update repository name (PR#559, 5cdb05e)
v7.33.2 (2023-02-17)
🪲 Bug Fixes
• Inconsistent versioning between print-version and publish (PR#524, 17d60e9)
v7.33.1 (2023-02-01)
🪲 Bug Fixes
• action: Mark container fs as safe for git (PR#552, 2a55f68)
v7.33.0 (2023-01-15)
✨ Features
• Add signing options to action (31ad5eb)
• Update action with configuration options (PR#518, 4664afe)
• repository: Add support for TWINE_CERT, closes #521 (PR#522, d56e85d)
🪲 Bug Fixes
• Changelog release commit search logic (PR#530, efb3410)
• github-actions: Bump Dockerfile to use Python 3.10 image, closes #533 (PR#536, 8f2185d)
• action: Fix environment variable names (3c66218)
📖 Documentation
• Update documentation (5cbdad2)
v7.32.2 (2022-10-22)
🪲 Bug Fixes
• Fix changelog generation in tag-mode (PR#171, 482a62e)
📖 Documentation
• Fix code blocks (PR#506, 24b7673)
v7.32.1 (2022-10-07)
🪲 Bug Fixes
• Corrections for deprecation warnings (PR#505, d47afb6)
📖 Documentation
• Correct spelling mistakes (PR#504, 3717e0d)
v7.32.0 (2022-09-25)
✨ Features
• Add setting for enforcing textual changelog sections, closes #498 (PR#502, 988437d)
📖 Documentation
• Correct documented default behavior for commit_version_number (PR#497, ffae2dc)
v7.31.4 (2022-08-23)
🪲 Bug Fixes
• Account for trailing newlines in commit messages, closes #490 (PR#495, 111b151)
v7.31.3 (2022-08-22)
🪲 Bug Fixes
• Use commit_subject when searching for release commits (PR#488, 3849ed9)
v7.31.2 (2022-07-29)
🪲 Bug Fixes
• Add better handling of missing changelog placeholder, closes #454 (e7a0e81)
• Add repo=None when not in git repo, closes #422 (40be804)
📖 Documentation
• Add example for pyproject.toml (2a4b8af)
v7.31.1 (2022-07-29)
🪲 Bug Fixes
• Update git email in action, closes #473 (0ece6f2)
v7.31.0 (2022-07-29)
✨ Features
• Add prerelease-patch and no-prerelease-patch flags for whether to auto-bump prereleases (b4e5b62)
• Override repository_url w REPOSITORY_URL env var (PR#439, cb7578c)
🪲 Bug Fixes
•
bug fix get_current_release_version for tag_only version_source (cad09be)
v7.30.2 (2022-07-26)
🪲 Bug Fixes
• Declare additional_options as action inputs (PR#481, cb5d8c7)
v7.30.1 (2022-07-25)
🪲 Bug Fixes
• Don't use commit_subject for tag pattern matching (PR#480, ac3f11e)
v7.30.0 (2022-07-25)
✨ Features
• Add additional_options input for GitHub Action (PR#477, aea60e3)
🪲 Bug Fixes
• Allow empty additional options (PR#479, c9b2514)
v7.29.7 (2022-07-24)
🪲 Bug Fixes
• Ignore dependency version bumps when parsing version from commit logs (PR#476, 51bcb78)
v7.29.6 (2022-07-15)
🪲 Bug Fixes
• Allow changing prerelease tag using CLI flags (PR#466, 395bf4f)
v7.29.5 (2022-07-14)
🪲 Bug Fixes
• Add packaging module requirement (PR#469, b99c9fa)
• publish: Get version bump for current release (PR#467, dd26888)
v7.29.4 (2022-06-29)
🪲 Bug Fixes
• Add text for empty ValueError (PR#461, 733254a)
v7.29.3 (2022-06-26)
🪲 Bug Fixes
• Ensure that assets can be uploaded successfully on custom GitHub servers (PR#458, 32b516d)
v7.29.2 (2022-06-20)
🪲 Bug Fixes
• Ensure should_bump checks against release version if not prerelease (PR#457, da0606f)
v7.29.1 (2022-06-01)
🪲 Bug Fixes
• Capture correct release version when patch has more than one digit (PR#448, 426cdc7)
v7.29.0 (2022-05-27)
✨ Features
• Allow using ssh-key to push version while using token to publish to hvcs (PR#419, 7b2dffa)
• config: Add ignore_token_for_push param (PR#419, 7b2dffa)
🪲 Bug Fixes
• Fix and refactor prerelease (PR#435, 94c9494)
• test: Override GITHUB_ACTOR env (PR#419, 7b2dffa)
📖 Documentation
• Add documentation for ignore_token_for_push (PR#419, 7b2dffa)
v7.28.1 (2022-04-14)
🪲 Bug Fixes
• Fix getting current version when version_source=tag_only (PR#437, b247936)
v7.28.0 (2022-04-11)
✨ Features
• Add tag_only option for version_source, closes #354 (PR#436, cf74339)
v7.27.1 (2022-04-03)
🪲 Bug Fixes
• prerelease: Pass prerelease option to get_current_version (PR#432, aabab0b)
v7.27.0 (2022-03-15)
✨ Features
• Add git-lfs to docker container (PR#427, 184e365)
v7.26.0 (2022-03-07)
✨ Features
• publish-cmd: add --prerelease cli flag to enable prerelease versioning (PR#413, 7064265)
• version-cmd: add --prerelease cli flag to enable prerelease versioning (PR#413, 7064265)
📖 Documentation
• Added basic info about prerelease versioning (PR#413, 7064265)
v7.25.2 (2022-02-24)
🪲 Bug Fixes
• gitea: Use form-data from asset upload (PR#421, e011944)
v7.25.1 (2022-02-23)
🪲 Bug Fixes
• gitea: Build status and asset upload (PR#420, 57db81f)
• gitea: Handle list build status response (PR#420, 57db81f)
v7.25.0 (2022-02-17)
✨ Features
• hvcs: Add gitea support (PR#412, b7e7936)
📖 Documentation
• Document tag_commit, closes #410 (b631ca0)
v7.24.0 (2022-01-24)
✨ Features
• Include additional changes in release commits (3e34f95)
v7.23.0 (2021-11-30)
✨ Features
• Support Github Enterprise server (b4e01f1)
v7.22.0 (2021-11-21)
✨ Features
• parser_angular: Allow customization in parser (298eebb)
🪲 Bug Fixes
• Address PR feedback for parser_angular.py (f7bc458)
v7.21.0 (2021-11-21)
✨ Features
• Use gitlab-ci or github actions env vars, closes #363 (8ca8dd4)
🪲 Bug Fixes
• Remove invalid repository exception (746b62d)
v7.20.0 (2021-11-21)
✨ Features
• Allow custom environment variable names (PR#392, 372cda3)
• Rewrite Twine adapter for uploading to artifact repositories (cfb20af)
🪲 Bug Fixes
• Don't use linux commands on windows (PR#393, 5bcccd2)
• Mypy errors in vcs_helpers (13ca0fe)
• Skip removing the build folder if it doesn't exist (8e79fdc)
📖 Documentation
• Clean typos and add section for repository upload (1efa18a)
v7.19.2 (2021-09-04)
🪲 Bug Fixes
• Fixed ImproperConfig import error (PR#377, b011a95)
v7.19.1 (2021-08-17)
🪲 Bug Fixes
• Add get_formatted_tag helper instead of hardcoded v-prefix in the git tags (1a354c8)
v7.19.0 (2021-08-16)
✨ Features
• Custom git tag format support (PR#373, 1d76632)
📖 Documentation
• configuration: define tag_format usage & resulting effect (PR#373, 1d76632)
• parser: Documentation for scipy-parser (45ee34a)
v7.18.0 (2021-08-09)
✨ Features
• Add support for non-prefixed tags (PR#366, 0fee4dd)
📖 Documentation
• Clarify second argument of ParsedCommit (086ddc2)
v7.17.0 (2021-08-07)
✨ Features
• parser: Add scipy style parser (PR#369, 51a3921)
v7.16.4 (2021-08-03)
🪲 Bug Fixes
• Correct rendering of gitlab issue references, closes #358 (07429ec)
v7.16.3 (2021-07-29)
🪲 Bug Fixes
• Print right info if token is not set, closes #360 (PR#361, a275a7a)
v7.16.2 (2021-06-25)
🪲 Bug Fixes
• Use release-api for gitlab (1ef5cab)
📖 Documentation
• Recommend setting a concurrency group for GitHub Actions (34b0735)
• Update trove classifiers to reflect supported versions (PR#344, 7578004)
v7.16.1 (2021-06-08)
🪲 Bug Fixes
• Tomlkit should stay at 0.7.0 (769a5f3)
v7.16.0 (2021-06-08)
✨ Features
• Add option to omit tagging (PR#341, 20603e5)
v7.15.6 (2021-06-08)
🪲 Bug Fixes
• Update click and tomlkit (PR#339, 947ea3b)
v7.15.5 (2021-05-26)
🪲 Bug Fixes
• Pin tomlkit to 0.7.0 (2cd0db4)
v7.15.4 (2021-04-29)
🪲 Bug Fixes
• Change log level of failed toml loading, closes #235 (24bb079)
v7.15.3 (2021-04-03)
🪲 Bug Fixes
• Add venv to path in github action (583c5a1)
v7.15.2 (2021-04-03)
🪲 Bug Fixes
• Run semantic-release in virtualenv in the github action, closes #331 (b508ea9)
• Set correct path for venv in action script (aac02b5)
• Use absolute path for venv in github action (d4823b3)
📖 Documentation
• Clarify that HVCS should be lowercase, closes #330 (da0ab0c)
v7.15.1 (2021-03-26)
🪲 Bug Fixes
• Add support for setting build_command to "false", closes #328 (520cf1e)
• Upgrade python-gitlab range, closes #329 (abfacc4)
📖 Documentation
• Add common options to documentation, closes #327 (20d79a5)
v7.15.0 (2021-02-18)
✨ Features
• Allow the use of .pypirc for twine uploads (PR#325, 6bc56b8)
📖 Documentation
• Add documentation for releasing on a Jenkins instance (PR#324, 77ad988)
v7.14.0 (2021-02-11)
✨ Features
• checks: Add support for Jenkins CI (PR#322, 3e99855)
📖 Documentation
• Correct casing on proper nouns (PR#320, d51b999)
• Correcting Python casing (PR#320, d51b999)
• Correcting Semantic Versioning casing (PR#320, d51b999)
v7.13.2 (2021-01-29)
🪲 Bug Fixes
• Crash when TOML has no PSR section (PR#319, 5f8ab99)
• Fix crash when TOML has no PSR section (PR#319, 5f8ab99)
📖 Documentation
• Fix version_toml example for Poetry (PR#318, 39acb68)
v7.13.1 (2021-01-26)
🪲 Bug Fixes
• Use multiline version_pattern match in replace, closes #306 (PR#315, 1a85af4)
v7.13.0 (2021-01-26)
✨ Features
• Support toml files for version declaration, closes #245, #275 (PR#307, 9b62a7e)
v7.12.0 (2021-01-25)
✨ Features
• github: Retry GitHub API requests on failure (PR#314, ac241ed)
🪲 Bug Fixes
• github: Add retries to github API requests (PR#314, ac241ed)
📖 Documentation
• actions: Pat must be passed to checkout step too, closes #311 (e2d8e47)
v7.11.0 (2021-01-08)
✨ Features
• print-version: Add print-version command to output version (512e3d9)
🪲 Bug Fixes
• Add dot to --define option help (eb4107d)
• Avoid Unknown bump level 0 message (8ab624c)
• actions: Fix github actions with new main location (6666672)
⚙️ Build System
• Add __main__.py magic file (e93f36a)
v7.10.0 (2021-01-08)
✨ Features
• build: Allow falsy values for build_command to disable build step (c07a440)
📖 Documentation
• Fix incorrect reference syntax (42027f0)
• Rewrite getting started page (97a9046)
v7.9.0 (2020-12-21)
✨ Features
• hvcs: Add hvcs_domain config option, closes #277 (ab3061a)
🪲 Bug Fixes
• history: Coerce version to string (PR#298, d4cdc3d)
• history: Require semver >= 2.10 (5087e54)
v7.8.2 (2020-12-19)
✨ Features
• repository: Add to settings artifact repository (f4ef373)
🪲 Bug Fixes
• cli: Skip remove_dist where not needed (04817d4)
v7.8.1 (2020-12-18)
🪲 Bug Fixes
• Filenames with unknown mimetype are now properly uploaded to github release (f3ece78)
• logs: Fix TypeError when enabling debug logs (2591a94)
v7.8.0 (2020-12-18)
✨ Features
• Add upload_to_pypi_glob_patterns option (42305ed)
🪲 Bug Fixes
• changelog: Use "issues" link vs "pull" (93e48c9)
• netrc: Prefer using token defined in GH_TOKEN instead of .netrc file (3af32a7)
v7.7.0 (2020-12-12)
✨ Features
• changelog: Add PR links in markdown (PR#282, 0448f6c)
v7.6.0 (2020-12-06)
✨ Features
• Add major_on_zero option (d324154)
📖 Documentation
• Add documentation for option major_on_zero (2e8b26e)
v7.5.0 (2020-12-04)
✨ Features
• logs: Include scope in changelogs (PR#281, 21c96b6)
v7.4.1 (2020-12-04)
🪲 Bug Fixes
• Add "changelog_capitalize" to flags, closes #278 (PR#279, 37716df)
v7.4.0 (2020-11-24)
✨ Features
• Add changelog_capitalize configuration, closes #260 (7cacca1)
📖 Documentation
• Fix broken internal references (PR#270, da20b9b)
• Update links to Github docs (PR#268, c53162e)
v7.3.0 (2020-09-28)
✨ Features
• Generate changelog.md file (PR#266, 2587dfe)
📖 Documentation
• Fix docstring (5a5e2cf)
v7.2.5 (2020-09-16)
🪲 Bug Fixes
• Add required to inputs in action metadata (PR#264, e76b255)
v7.2.4 (2020-09-14)
🪲 Bug Fixes
• Use range for toml dependency, closes #241 (45707e1)
v7.2.3 (2020-09-12)
🪲 Bug Fixes
• Support multiline version_pattern matching by default (82f7849)
📖 Documentation
• Create 'getting started' instructions (PR#256, 5f4d000)
• Link to getting started guide in README (f490e01)
v7.2.2 (2020-07-26)
🪲 Bug Fixes
• changelog: Send changelog to stdout, closes #250 (87e2bb8)
📖 Documentation
• Add quotation marks to the pip commands in CONTRIBUTING.rst (PR#253, e20fa43)
v7.2.1 (2020-06-29)
🪲 Bug Fixes
• Commit all files with bumped versions (PR#249, b3a1766)
📖 Documentation
• Give example of multiple build commands (PR#248, 65f1ffc)
v7.2.0 (2020-06-15)
✨ Features
• Bump versions in multiple files, closes #175 (PR#246, 0ba2c47)
v7.1.1 (2020-05-28)
🪲 Bug Fixes
• changelog: Swap sha and message in table changelog (6741370)
v7.1.0 (2020-05-24)
✨ Features
• changelog: Add changelog_table component, closes #237 (PR#242, fe6a7e7)
v7.0.0 (2020-05-22)
✨ Features
• Pass changelog_sections to components (PR#240, 3e17a98)
• changelog: Add changelog components (PR#240, 3e17a98)
📖 Documentation
• Add conda-forge badge (e9536bb)
• Add documentation for changelog_components (PR#240, 3e17a98)
💥 BREAKING CHANGES
• changelog: The compare_url option has been removed in favor of using changelog_components. This
functionality is now available as the semantic_release.changelog.compare_url component.
v6.4.1 (2020-05-15)
🪲 Bug Fixes
• Convert \r\n to \n in commit messages, closes #239 (34acbbc)
v6.4.0 (2020-05-15)
✨ Features
• history: Create emoji parser (PR#238, 2e1c50a)
🪲 Bug Fixes
• Add emojis to default changelog_sections (PR#238, 2e1c50a)
• Include all parsed types in changelog (PR#238, 2e1c50a)
📖 Documentation
• Add documentation for emoji parser (PR#238, 2e1c50a)
♻️ Refactoring
• history: Get breaking changes in parser (PR#238, 2e1c50a)
v6.3.1 (2020-05-11)
🪲 Bug Fixes
• Use getboolean for commit_version_number, closes #186 (a60e0b4)
v6.3.0 (2020-05-09)
✨ Features
• history: Support linking compare page in changelog, closes #218 (79a8e02)
📖 Documentation
• Document compare_link option (e52c355)
• Rewrite commit-log-parsing.rst (4c70f4f)
v6.2.0 (2020-05-02)
✨ Features
• history: Check all paragraphs for breaking changes, closes #200 (fec08f0)
📖 Documentation
• Add = to verbosity option, closes #227 (a0f4c9c)
• Use references where possible, closes #221 (f38e5d4)
v6.1.0 (2020-04-26)
✨ Features
• actions: Support PYPI_TOKEN on GitHub Actions (df2c080)
• pypi: Support easier use of API tokens, closes #213 (bac135c)
📖 Documentation
• Add documentation for PYPI_TOKEN (a8263a0)
v6.0.1 (2020-04-15)
🪲 Bug Fixes
• hvcs: Convert get_hvcs to use LoggedFunction (3084249)
v6.0.0 (2020-04-15)
📖 Documentation
• Create Read the Docs config file (aa5a1b7)
• Include README.rst in index.rst (8673a9d)
• Move action.rst into main documentation (509ccaf)
• Rewrite README.rst (e049772)
• Rewrite troubleshooting page (0285de2)
♻️ Refactoring
• debug: Use logging and click_log instead of ndebug (15b1f65)
💥 BREAKING CHANGES
• debug: debug="*" no longer has an effect, instead use --verbosity DEBUG.
v5.2.0 (2020-04-09)
✨ Features
• github: Add tag as default release name (2997908)
📖 Documentation
• Automate API docs (7d4fea2)
v5.1.0 (2020-04-04)
✨ Features
• history: Allow customizing changelog_sections (PR#207, d5803d5)
📖 Documentation
• Improve formatting of configuration page (9a8e22e)
• Improve formatting of envvars page (b376a56)
• Update index.rst (b27c26c)
v5.0.3 (2020-03-26)
🪲 Bug Fixes
• Bump dependencies and fix Windows issues on Development (PR#173, 0a6f8c3)
• Missing mime types on Windows (PR#173, 0a6f8c3)
v5.0.2 (2020-03-22)
🪲 Bug Fixes
• history: Leave case of other characters unchanged (96ba94c)
v5.0.1 (2020-03-22)
🪲 Bug Fixes
• Make action use current version of semantic-release (123984d)
v5.0.0 (2020-03-22)
✨ Features
• build: Allow config setting for build command, closes #188 (PR#195, 740f4bd)
🪲 Bug Fixes
• Rename default of build_command config (d5db22f)
📖 Documentation
• pypi: Update docstrings in pypi.py (6502d44)
💥 BREAKING CHANGES
• build: Previously the build_commands configuration variable set the types of bundles sent to python
setup.py. It has been replaced by the configuration variable build_command which takes the full command
e.g. python setup.py sdist or poetry build.
v4.11.0 (2020-03-22)
✨ Features
• actions: Create GitHub Action (350245d)
📖 Documentation
• Make AUTHORS.rst dynamic (db2e076)
• readme: Fix minor typo (c22f69f)
v4.10.0 (2020-03-03)
✨ Features
• Make commit message configurable (PR#184, eb0762c)
v4.9.0 (2020-03-02)
✨ Features
• pypi: Add build_commands config (22146ea)
🪲 Bug Fixes
• pypi: Change bdist_wheels to bdist_wheel (c4db509)
v4.8.0 (2020-02-28)
✨ Features
• git: Add a new config for commit author (aa2c22c)
v4.7.1 (2020-02-28)
🪲 Bug Fixes
• Repair parsing of remotes in the gitlab ci format, closes #181 (0fddbe2)
v4.7.0 (2020-02-28)
✨ Features
• Upload distribution files to GitHub Releases (PR#177, e427658)
• github: Upload dists to release (PR#177, e427658)
🪲 Bug Fixes
• Post changelog after PyPI upload (PR#177, e427658)
• Support repository owner names containing dots, closes #179 (a6c4da4)
• github: Fix upload of .whl files (PR#177, e427658)
• github: Use application/octet-stream for .whl files (90a7e47)
📖 Documentation
• Document upload_to_release config option (PR#177, e427658)
v4.6.0 (2020-02-19)
✨ Features
• history: Capitalize changelog messages (1a8e306)
🪲 Bug Fixes
• Add more debug statements in logs (bc931ec)
• Only overwrite with patch if bump is None, closes #159 (1daa4e2)
v4.5.1 (2020-02-16)
🪲 Bug Fixes
• github: Send token in request header, closes #167 (be9972a)
📖 Documentation
• Add note about automatic releases in readme (e606e75)
• Fix broken list in readme (7aa572b)
• Update readme and getting started docs (07b3208)
v4.5.0 (2020-02-08)
✨ Features
• history: Enable colon defined version, closes #165 (7837f50)
🪲 Bug Fixes
• Remove erroneous submodule (762bfda)
• cli: --noop flag works when before command, closes #73 (4fcc781)
v4.4.1 (2020-01-18)
🪲 Bug Fixes
• Add quotes around twine arguments, closes #163 (46a83a9)
v4.4.0 (2020-01-17)
✨ Features
• parser: Add support for exclamation point for breaking changes, closes #156 (a4f8a10)
• parser: Make BREAKING-CHANGE synonymous with BREAKING CHANGE (beedccf)
🪲 Bug Fixes
• github: Add check for GITHUB_ACTOR for git push (PR#162, c41e9bb)
v4.3.4 (2019-12-17)
🪲 Bug Fixes
• Fallback to whole log if correct tag is not available, closes #51 (PR#157, 252bffd)
v4.3.3 (2019-11-06)
🪲 Bug Fixes
• Instead of requiring click 7.0, looks like all tests will pass with at least 2.0. (PR#155, f07c7f6)
• Set version of click to >=2.0,<8.0. (PR#155, f07c7f6)
• Upgrade to click 7.0, closes #117 (PR#155, f07c7f6)
v4.3.2 (2019-10-05)
🪲 Bug Fixes
• Update regex to get repository owner and name for project with dots, closes #151 (2778e31)
v4.3.1 (2019-09-29)
🪲 Bug Fixes
• Support repo urls without git terminator (700e9f1)
v4.3.0 (2019-09-06)
✨ Features
• Add the possibility to load configuration from pyproject.toml (35f8bfe)
• Allow the override of configuration options from cli, closes #119 (f0ac82f)
• Allow users to get version from tag and write/commit bump to file, closes #104 (1f9fe1c)
• Make the vcs functionalities work with gitlab, closes #121 (82d555d)
🪲 Bug Fixes
• Manage subgroups in git remote url, closes #139, #140 (4b11875)
• Update list of commit types to include build, ci and perf, closes #145 (41ea12f)
v4.2.0 (2019-08-05)
✨ Features
• Add configuration to customize handling of dists, closes #115 (2af6f41)
• Add support for configuring branch, closes #43 (14abb05)
• Add support for showing unreleased changelog, closes #134 (41ef794)
🪲 Bug Fixes
• Add commit hash when generating breaking changes, closes #120 (0c74faf)
• Kept setting new version for tag source (0e24a56)
• Remove deletion of build folder, closes #115 (b45703d)
• Updated the tag tests (3303eef)
• Upgrade click to 7.0 (2c5dd80)
v4.1.2 (2019-08-04)
🪲 Bug Fixes
• Correct isort build fail (0037210)
• Make sure the history only breaks loop for version commit, closes #135 (5dc6cfc)
• vcs: Allow cli to be run from subdirectory (fb7bb14)
📖 Documentation
• circleci: Point badge to master branch (9c7302e)
v4.1.1 (2019-02-15)
📖 Documentation
• Correct usage of changelog (f4f59b0)
• Debug usage and related (f08e594)
• Describing the commands (b6fa04d)
• Update url for commit guidelinesThe guidelines can now be found in theDEVELOPERS.md in angular. (‐
90c1b21)
v4.1.0 (2019-01-31)
✨ Features
• ci_checks: Add support for bitbucket (9fc120d)
🪲 Bug Fixes
• Initialize git Repo from current folder (c7415e6)
• Maintain version variable formatting on bump (PR#103, bf63156)
• Use same changelog code for command as post (248f622)
📖 Documentation
• Add installation instructions for development (PR#106, 9168d0e)
• readme: Add testing instructions (bb352f5)
v4.0.1 (2019-01-12)
🪲 Bug Fixes
• Add better error message when pypi credentials are empty, closes #96 (c4e5dcb)
• Clean out dist and build before building, closes #86 (b628e46)
• Filter out pypi secrets from exceptions, closes #41 (5918371)
• Unfreeze dependencies, closes #100 (847833b)
• Use correct syntax to exclude tests in package, closes #92 (3e41e91)
• parser_angular: Fix non-match when special chars in scope (8a33123)
📖 Documentation
• Remove reference to gitter, closes #90 (896e37b)
v4.0.0 (2018-11-22)
✨ Features
• Add support for commit_message config variable (4de5400)
• CI checks: Add support for GitLab CI checks, closes #88 (8df5e2b)
🪲 Bug Fixes
• Add check of credentials (7d945d4)
• Add credentials check (0694604)
• Add dists to twine call (1cec2df)
• Change requests from fixed version to version range (PR#93, af3ad59)
• Re-add skip-existing (366e9c1)
• Remove repository argument in twine (e24543b)
• Remove universal from setup config (18b2402)
• Update twine (c4ae7b8)
• Use new interface for twine (c04872d)
• Use twine through cli call (ab84beb)
📖 Documentation
• Add type hints and more complete docstrings, closes #81 (a6d5e9b)
• Fix typo in documentation index (da6844b)
♻️ Refactoring
• Remove support for python 2 (85fe638)
💥 BREAKING CHANGES
• If you rely on the commit message to be the version number only, this will break your code
• This will only work with python 3 after this commit.
v3.11.2 (2018-06-10)
🪲 Bug Fixes
• Upgrade twine (9722313)
v3.11.1 (2018-06-06)
🪲 Bug Fixes
• Change Gitpython version number, closes #80 (23c9d4b)
📖 Documentation
• Add retry option to cli docs (021da50)
v3.11.0 (2018-04-12)
✨ Features
• Add --retry cli option (PR#78, 3e312c0)
• Add support to finding previous version from tags if not using commit messages (PR#68, 6786487)
• Be a bit more forgiving to find previous tags (PR#68, 6786487)
🪲 Bug Fixes
• Add pytest cache to gitignore (b8efd5a)
• Make repo non if it is not a git repository, closes #74 (1dc306b)
📖 Documentation
• Define --retry usage (3e312c0)
• Remove old notes about trello board (7f50c52)
• Update status badges (cfa13b8)
v3.10.3 (2018-01-29)
🪲 Bug Fixes
• Error when not in git repository, closes #74 (PR#75, 251b190)
v3.10.2 (2017-08-03)
🪲 Bug Fixes
• Update call to upload to work with twine 1.9.1 (PR#72, 8f47643)
v3.10.1 (2017-07-22)
🪲 Bug Fixes
• Update Twine (PR#69, 9f268c3)
v3.10.0 (2017-05-05)
✨ Features
• Add git hash to the changelog (PR#65, 628170e)
🪲 Bug Fixes
• Make changelog problems not fail whole publish (b5a68cf)
📖 Documentation
• Fix typo in cli.py docstring (PR#64, 0d13985)
v3.9.0 (2016-07-03)
✨ Features
• Add option for choosing between versioning by commit or tag (c0cd1f5)
• Don't use file to track version, only tag to commit for versioning (cd25862)
• Get repo version from historical tags instead of config file (a45a9bf)
🪲 Bug Fixes
• Can't get the proper last tag from commit history (5a0e681)
v3.8.1 (2016-04-17)
🪲 Bug Fixes
• Add search_parent_directories option to gitpython (PR#62, 8bf9ce1)
v3.8.0 (2016-03-21)
✨ Features
• Add ci checks for circle ci (151d849)
🪲 Bug Fixes
• Add git fetch to frigg after success (74a6cae)
• Make tag parser work correctly with breaking changes (9496f6a)
• Refactoring cli.py to improve --help and error messages (c79fc34)
📖 Documentation
• Add info about correct commit guidelines (af35413)
• Add info about trello board in readme (5229557)
• Fix badges in readme (7f4e549)
• Update info about releases in contributing.md (466f046)
v3.7.2 (2016-03-19)
🪲 Bug Fixes
• Move code around a bit to make flake8 happy (41463b4)
v3.7.1 (2016-03-15)
📖 Documentation
• configuration: Fix typo in setup.cfg section (725d87d)
v3.7.0 (2016-01-10)
✨ Features
• Add ci_checks for Frigg CI (577c374)
v3.6.1 (2016-01-10)
🪲 Bug Fixes
• Add requests as dependency (4525a70)
v3.6.0 (2015-12-28)
✨ Features
• Add checks for semaphore, closes #44 (2d7ef15)
📖 Documentation
• Add documentation for configuring on CI (7806940)
• Add note about node semantic release (0d2866c)
• Add step by step guide for configuring travis ci (6f23414)
• Move automatic-releases to subfolder (ed68e5b)
• Remove duplicate readme (42a9421)
v3.5.0 (2015-12-22)
✨ Features
• Add author in commit, closes #40 (020efaa)
• Checkout master before publishing (dc4077a)
🪲 Bug Fixes
• Remove " from git push command (031318b)
📖 Documentation
• Convert readme to rst (e8a8d26)
v3.4.0 (2015-12-22)
✨ Features
• Add travis environment checks (f386db7)
v3.3.3 (2015-12-22)
🪲 Bug Fixes
• Do git push and git push --tags instead of --follow-tags (8bc70a1)
v3.3.2 (2015-12-21)
🪲 Bug Fixes
• Change build badge (0dc068f)
📖 Documentation
• Update docstrings for generate_changelog (987c6a9)
v3.3.1 (2015-12-21)
🪲 Bug Fixes
• Add pandoc to travis settings (17d40a7)
• Only list commits from the last version tag, closes #28 (191369e)
v3.3.0 (2015-12-20)
✨ Features
• Add support for environment variables for pypi credentials (3b383b9)
🪲 Bug Fixes
• Add missing parameters to twine.upload (4bae22b)
• Better filtering of github token in push error (9b31da4)
• Downgrade twine to version 1.5.0 (66df378)
• Make sure the github token is not in the output (55356b7)
• Push to master by default (a0bb023)
v3.2.1 (2015-12-20)
🪲 Bug Fixes
• Add requirements to manifest (ed25ecb)
• pypi: Add sdist as default in addition to bdist_wheel (a1a35f4)
v3.2.0 (2015-12-20)
✨ Features
• angular-parser: Remove scope requirement (90c9d8d)
• git: Add push to GH_TOKEN@github-url (546b5bf)
🪲 Bug Fixes
• deps: Use one file for requirements (4868543)
v3.1.0 (2015-08-31)
✨ Features
• pypi: Add option to disable pypi upload (f5cd079)
v3.0.0 (2015-08-25)
✨ Features
• parser: Add tag parser (a7f392f)
🪲 Bug Fixes
• errors: Add exposing of errors in package (3662d76)
• version: Parse file instead for version (005dba0)
v2.1.4 (2015-08-24)
🪲 Bug Fixes
• github: Fix property calls (7ecdeb2)
v2.1.3 (2015-08-22)
🪲 Bug Fixes
• hvcs: Make Github.token an property (37d5e31)
📖 Documentation
• api: Update apidocs (6185380)
• parsers: Add documentation about commit parsers (9b55422)
• readme: Update readme with information about the changelog command (56a745e)
v2.1.2 (2015-08-20)
🪲 Bug Fixes
• cli: Fix call to generate_changelog in publish (5f8bce4)
v2.1.1 (2015-08-20)
🪲 Bug Fixes
• history: Fix issue in get_previous_version (f961786)
v2.1.0 (2015-08-20)
✨ Features
• cli: Add the possibility to re-post the changelog (4d028e2)
🪲 Bug Fixes
• cli: Fix check of token in changelog command (cc6e6ab)
• github: Fix the github releases integration (f0c3c1d)
• history: Fix changelog generation (f010272)
v2.0.0 (2015-08-19)
✨ Features
• cli: Add command for printing the changelog (336b8bc)
• github: Add github release changelog helper (da18795)
• history: Add angular parser (91e4f0f)
• history: Add generate_changelog function (347f21a)
• history: Add markdown changelog formatter (d77b58d)
• history: Set angular parser as the default (c2cf537)
• publish: Add publishing of changelog to github (74324ba)
• settings: Add loading of current parser (7bd0916)
🪲 Bug Fixes
• cli: Change output indentation on changelog (2ca41d3)
• history: Fix level id's in angular parser (2918d75)
• history: Fix regex in angular parser (974ccda)
• history: Support unexpected types in changelog generator (13deacf)
💥 BREAKING CHANGES
• history: The default parser is now angular. Thus, the default behavior of the commit log evaluator will
change. From now on it will use the angular commit message spec to determine the new version.
v1.0.0 (2015-08-04)
💥 Breaking
• Restructure helpers into history and pypi (00f64e6)
📖 Documentation
• Add automatic publishing documentation, resolves #18 (58076e6)
v0.9.1 (2015-08-04)
🪲 Bug Fixes
• Fix get_current_head_hash to ensure it only returns the hash (7c28832)
v0.9.0 (2015-08-03)
✨ Features
• Add Python 2.7 support, resolves #10 (c05e13f)
v0.8.0 (2015-08-03)
✨ Features
• Add check_build_status option, resolves #5 (310bb93)
• Add get_current_head_hash in git helpers (d864282)
• Add git helper to get owner and name of repo (f940b43)
v0.7.0 (2015-08-02)
✨ Features
• Add patch_without_tag option, resolves #6 (3734a88)
📖 Documentation
• Set up sphinx based documentation, resolves #1 (41fba78)
v0.6.0 (2015-08-02)
✨ Features
• Add twine for uploads to pypi, resolves #13 (eec2561)
v0.5.4 (2015-07-29)
🪲 Bug Fixes
• Add python2 not supported warning (e84c4d8)
v0.5.3 (2015-07-28)
⚙️ Build System
• Add wheel as a dependency (971e479)
v0.5.2 (2015-07-28)
🪲 Bug Fixes
• Fix python wheel tag (f9ac163)
v0.5.1 (2015-07-28)
🪲 Bug Fixes
• Fix push commands (8374ef6)
v0.5.0 (2015-07-28)
✨ Features
• Add setup.py hook for the cli interface (c363bc5)
v0.4.0 (2015-07-28)
✨ Features
• Add publish command (d8116c9)
v0.3.2 (2015-07-28)
• No change
v0.3.1 (2015-07-28)
🪲 Bug Fixes
• Fix wheel settings (1e860e8)
v0.3.0 (2015-07-27)
✨ Features
• Add support for tagging releases (5f4736f)
🪲 Bug Fixes
• Fix issue when version should not change (441798a)
v0.2.0 (2015-07-27)
✨ Features
• added no-operation (--noop) mode (44c2039)
⚙️ Build System
• Swapped pygit2 with gitpython to avoid libgit2 dependency (8165a2e)
v0.1.1 (2015-07-27)
🪲 Bug Fixes
• Fix entry point (bd7ce7f)
v0.1.0 (2015-07-27)
• Initial Release
GETTING STARTED
If you haven't done so already, install Python Semantic Release following the instructions above.
There is no strict requirement to have it installed locally if you intend on using a CI service, however
running with --noop can be useful to test your configuration.
Generating your configuration
Python Semantic Release ships with a command-line interface, semantic-release. You can inspect the
default configuration in your terminal by running
semantic-release generate-config
You can also use the -f/--format option to specify what format you would like this configuration to be.
The default is TOML, but JSON can also be used.
You can append the configuration to your existing pyproject.toml file using a standard redirect, for
example:
semantic-release generate-config --pyproject >> pyproject.toml
and then editing to your project's requirements.
SEE ALSO:
• semantic-release generate-config
• Configuration
Setting up version numbering
Create a variable set to the current version number. This could be anywhere in your project, for example
setup.py:
from setuptools import setup
__version__ = "0.0.0"
setup(
name="my-package",
version=__version__,
# And so on...
)
Python Semantic Release can be configured using a TOML or JSON file; the default configuration file is
pyproject.toml, if you wish to use another file you will need to use the -c/--config option to specify
the file.
Set version_variables to a list, the only element of which should be the location of your version
variable inside any Python file, specified in standard module:attribute syntax:
pyproject.toml:
[tool.semantic_release]
version_variables = ["setup.py:__version__"]
SEE ALSO:
• Configuration - tailor Python Semantic Release to your project
Setting up commit parsing
We rely on commit messages to detect when a version bump is needed. By default, Python Semantic Release
uses the Conventional Commits Specification to parse commit messages. You can find out more about this in
Commit Parsing.
SEE ALSO:
• branches - Adding configuration for releases from multiple branches.
• commit_parser - use a different parser for commit messages. For example, Python Semantic Release
also ships with emoji and scipy-style parsers.
• remote.type - specify the type of your remote VCS.
Setting up the changelog
SEE ALSO:
• Changelog - Customize the changelog generated by Python Semantic Release.
• Migrating an Existing Changelog
Creating VCS Releases
You can set up Python Semantic Release to create Releases in your remote version control system, so you
can publish assets and release notes for your project.
In order to do so, you will need to place an authentication token in the appropriate environment variable
so that Python Semantic Release can authenticate with the remote VCS to push tags, create releases, or
upload files.
GitHub (GH_TOKEN)
For local publishing to GitHub, you should use a personal access token and store it in your environment
variables. Specify the name of the environment variable in your configuration setting remote.token. The
default is GH_TOKEN.
To generate a token go to https://github.com/settings/tokens and click on "Generate new token".
For Personal Access Token (classic), you will need the repo scope to write (ie. push) to the repository.
For fine-grained Personal Access Tokens, you will need the contents permission.
GitLab (GITLAB_TOKEN)
A personal access token from GitLab. This is used for authenticating when pushing tags, publishing
releases etc. This token should be stored in the GITLAB_TOKEN environment variable.
Gitea (GITEA_TOKEN)
A personal access token from Gitea. This token should be stored in the GITEA_TOKEN environment variable.
Bitbucket (BITBUCKET_TOKEN)
Bitbucket does not support uploading releases but can still benefit from automated tags and changelogs.
The user has three options to push changes to the repository:
1. Use SSH keys.
2. Use an App Secret, store the secret in the BITBUCKET_TOKEN environment variable and the username in
BITBUCKET_USER.
3. Use an Access Token for the repository and store it in the BITBUCKET_TOKEN environment variable.
SEE ALSO:
• Changelog - customize your project's changelog.
• Custom Release Notes - customize the published release notes
• upload_to_vcs_release - enable/disable uploading artifacts to VCS releases
• version --vcs-release/--no-vcs-release - enable/disable VCS release creation.
• upload-to-gh-release, a GitHub Action for running semantic-release publish
Running from setup.py
Add the following hook to your setup.py and you will be able to run python setup.py <command> as you
would semantic-release <command>:
try:
from semantic_release import setup_hook
setup_hook(sys.argv)
except ImportError:
pass
NOTE:
Only the version, publish, and changelog commands may be invoked from setup.py in this way.
Running on CI
Getting a fully automated setup with releases from CI can be helpful for some projects. See Automatic
Releases.
AUTHOR
Python Semantic Release Team
COPYRIGHT
2024, Python Semantic Release Team
9.21.0 Feb 26, 2025 PYTHON-SEMANTIC-RELEASE(1)