Releases are automated via release-please. The process is driven entirely by conventional commits merged to main.
- Every push to
maintriggers therelease-pleasejob in.github/workflows/release.yml. - release-please opens (or updates) a release PR that:
- Bumps the version in
pyproject.toml, all sub-packagepyproject.tomlfiles, and__init__.pyfiles - Bumps
appVersionindeployment/k8s/charts/Chart.yaml - Updates
CHANGES.mdwith the changelog for the new version
- Bumps the version in
- When that PR is merged, release-please creates a GitHub release tagged
X.Y.Z. The release is authored via a GitHub App token (not the defaultGITHUB_TOKEN), which is what lets therelease: publishedevent trigger the PyPI publish and AWS deploy workflows — events from the defaultGITHUB_TOKENdo not cascade into new workflow runs, so a bot-authored release would otherwise publish nothing.
The Helm chart version: in deployment/k8s/charts/Chart.yaml is not managed by release-please. The chart version is bumped manually when chart structure changes (templates, values, dependencies). The appVersion field (the titiler app version the chart deploys) is still updated automatically alongside every Python release, and as part of this process, the chart version can be manually updated by bumping the version in a simple commit in the release please PR.
Version bumps follow semantic versioning based on commit type:
| Commit type | Version bump |
|---|---|
fix: |
patch |
feat: |
minor |
feat!: or BREAKING CHANGE: footer |
major |
All version files are updated automatically. Do not manually edit version strings in pyproject.toml, Chart.yaml (appVersion), or __init__.py files — release-please owns those. The version: field in Chart.yaml is the only exception: bump it manually when chart structure changes warrant a new chart release.