Release Process

Medix uses Release Please for fully automated, Conventional-Commits-driven releases.

The flow

conventional commit on main
        │
        ▼
release-please.yml opens or updates a release PR
        │
        ▼
maintainer merges the release PR
        │
        ▼
GitHub release is cut + tag is pushed
        │
        ▼
publish job builds and uploads to PyPI (OIDC, no tokens)
        │
        ▼
docs redeploy if /docs was touched (Cloudflare Pages)

Version bumping rules

Release Please infers the bump from commit prefixes since the last release:

Commit	Bump
`fix: …`	patch (1.3.0 → 1.3.1)
`feat: …`	minor (1.3.0 → 1.4.0)
`feat!: …` or `BREAKING CHANGE:` in body	major (1.3.0 → 2.0.0)
`chore:`, `docs:`, `refactor:`, `test:`, `ci:`, `style:`	no bump

Release PR

When release-worthy commits land on main, Release Please opens (or updates) a PR titled chore(main): release medix <new-version>. That PR:

Bumps pyproject.toml version
Bumps medix/__init__.py __version__
Updates CHANGELOG.md
Updates .release-please-manifest.json

Merging the PR fires the publish job.

Publishing

The publish job uses PyPI’s OIDC trusted publisher flow — no long-lived API tokens, no secrets. It:

Checks out the tagged commit
Sets up Python 3.12
Runs python -m build
Uses pypa/gh-action-pypi-publish to upload to PyPI

The built wheel and sdist appear on both pypi.org and libraries.io.

Docs deployment

Docs live in docs/ and deploy to Cloudflare Pages on push to main — but only when files under docs/ change. This keeps the package release and docs release independent.

Hotfixes

For urgent fixes that can’t wait for a normal release:

Land the fix on main as fix: …
Release Please opens a release PR automatically
Merge it immediately

There’s no separate hotfix branch — the workflow is fast enough.