Releasing

This page is intended for project maintainers (@armkhudinyan and @eliocp). It describes how the package may be built and published to PyPI and how GitHub releases may be created after successful merge pull requests.

Requirements

To publish the package to PyPI and create a GitHub release, you would need:

uv project manager.
git version control system.
Repo owner CoLAB-ATLANTIC set as a trusted publisher of the PyPI project.

Release Workflow

Approve pull request

Review a pull request into main, provide comments, request changes if necessary, and approve it when appropriate.

Note

Automatic executions after approval of a pull request

As defined in the GitHub workflow file ci.yml, several checks are executed by GitHub after a pull request being approved:

Code lint check (using ruff check).
Code format check (using ruff format --check).

Note that although the workflow uses push to in the mapping of the trigger, approval of pull requests are also included since these always involve a push. Also note that regardless of any fail in workflow, the completion of the pull request proceeds.

Update project version

Switch to the main branch, pull the changes associated with the pull request and update the version of the project stated in pyproject.toml:
```
git switch main
git pull
uv version VERSION
```
where VERSION is the version.

Commit and push this change:

git add -A
git commit -m "Updated project version."
git push

Create release tag

Associate tag VERSION (the version considered in the previous step) with the latest commit and push the tag to the remote repo:
```
git tag VERSION
git push origin VERSION
```

Note

Semantic versioning

VERSION must satisfy the semantic versioning rules as described in the table below.

Release Type	Example
Major release	v1.0.0
Minor release	v1.1.0
Patch release	v1.1.1
Alpha pre-release	v1.1.1-alpha.1
Beta pre-release	v1.1.1-beta.1
Release candidate	v1.1.1.-rc.1

Let GitHub Actions automatically build and publish the package to PyPI, and deploy the documentation to GitHub Pages

After pushing the tag, the package is automatically built and published to PyPI by GitHub using workflow file build-publish-package.yml. The published new version of the package would then appear in the project s3lst-ds hosted in the PyPI website. Moreover, the documentation would also be published to GitHub Pages using workflow file publish-docs.yml.

Note

The Continuous Integration workflow file ci.yml would identically run since it is triggered by any kind of push.

(Optional) Create GitHub release

If desired, create a GitHub release by going to the GitHub page, clicking on Releases, then Draft a new release and issuing a title (usually the project version VERSION) and some notes. After this, the GitHub release would then appear in the Releases section of the repo GitHub page.

Note

GitHub release

GitHub releases are portable "snapshots" of a specific version (commit) of the project containing release notes and source archives (zip and tar.gz files) which may be used in other contexts outside of GitHub.