Release Process

This page describes the process which should used to create an official package release. Releases should be performed frequently as changes add up. The first release should be v0.1.0.

Versioning

We will be using Semantic versioning which is a widely-adopted version scheme that uses a three-part version number (Major.Minor.Patch).

Tagging

You need to create a tag in the git history. A tag is simply a marker at a particular point in the list of commits in the git history.

We will be using light weight tags. To create a tag

git tag v1.4.1

You then have to push the tag to the server with

git push origin v1.4.1

On github, click on the tags link and just select Releases. Select the right tag and then fill out the form. The title of the release should be same as your tag. In the body, title the page with your tag and the release date like so # v1.4.1 (2022-01-06). Below that list each of the changes in the following categories, new features, bug fixes, documentation, internal changes. See the following link for a good example.

Building a Release

This package will not be released to PyPI until it hits version 1.0. The following describes the steps to build, test, and upload a release to PyPi

Build

To build and upload your package to PyPI, you’ll use two tools called Build and Twine. You can install them using pip as usual:

python3 -m pip install build twine

Next, build the package

python3 -m build

This creates a source archive and a wheel. You can find them in a newly created dist directory.

Before uploading your newly built distribution packages, you should check that they contain the files you expect. The wheel file is really a with a different extension. You can unzip it and inspect its contents.