Skip to content

Releases

We use the PEP440 standard for release versions. This section guides you through how to release new versions as a maintainer.

Generating releases

To aid in managing automated changelogs and package version control, this codebase uses the Commitizen package (installed as dev dependency). Please note that Commitizen has an automated approach of inferring what semantic versioning level the next bump should be (See last sub-section of this page).

To bump to the next stable version:

cz bump

Examples:

v0.0.1 → v0.0.2

Create a Pre-release

Commitizen supports alpha, beta, and release candidate (RC) pre-releases using the --prerelease flag.

Alpha (a)

cz bump --prerelease alpha

Examples:

v1.0.4 → v1.0.5a0

Beta (b)

cz bump --prerelease beta

Examples:

v1.0.5a2 → v1.0.5b0

Release Candidate (rc)

cz bump --prerelease rc

Examples:

v1.0.5b2 → v1.0.5rc0

Explicit patch-level prerelease

Commitizen will automatically infer the SemVer level based on the commit history. While this can be nice, you might want to define your own release definition like I have been doing till hitting production stage.

To start a new patch-level prerelease explicitly rather than letting commitizen infer it:

cz bump --increment patch --prerelease alpha

Examples:

v1.2.4a3 → v1.2.5a0

In this case, without specifying we want to increment the patch number, it will increment the alpha version instead!

Note

This project follows PEP 440 versioning. Pre-releases use a (alpha), b (beta), or rc (release candidate) without hyphens or dots (e.g., 1.2.5a1 not 1.2.5-alpha.1) unlike SemVer.

Examples: 1.2.5a1, 1.2.5b2, 1.2.5rc1, 1.2.5.dev0

For full documentation on its usage, please peruse the Commitizen docs.