Skip to content

Releases

A release of an entirius-py-* or entirius-django-* package is a commit, a pull request, a tag and a GitHub release. Maintainers cut releases. A contribution does not touch the version or the changelog unless the review asks for it.

How versions are numbered and what a release promises: Versioning and Upgrades. At release time the maintainer decides two things:

  • The number. Patch for a fix, minor for a new capability that breaks no caller, major when an interface breaks.
  • The changelog entry. What changed, in the words of someone who installs the package, with an Upgrade subsection when the version needs a manual step.

The version is written in one place, the [project] table of pyproject.toml:

[project]
version = "3.3.1"
  1. On develop, land a chore: release <version> commit. It bumps version in pyproject.toml, adds the entry to CHANGELOG.md (creating the file in a repository that has none yet) and refreshes uv.lock. It can be the last commit of the branch that completes the release.
  2. Open a pull request from develop to master. The required checks run on it as on any pull request (CI/CD).
  3. A maintainer merges it with a merge commit.
  4. Tag that merge commit on master as v<version>, for example v3.3.1. Every tag lives on master.
  5. Publish a GitHub release from the tag, with the changelog entry as its description.
  6. The publish.yml workflow runs on the published release, builds the package and uploads it to PyPI.

A fix that cannot wait for the next planned release takes the same path: a fix/<name> branch into develop, then steps 1 to 6 with a patch version.

Packages are published to PyPI, and a service declares them as ordinary dependencies with a lower bound:

[project]
dependencies = ["entirius-django-pim>=3.3.1"]

The upload uses PyPI trusted publishing, so no repository stores an upload token: CI/CD. Moving an installation to a new version: Taking an Upgrade.