Publishing is automated; you never run twine upload or create tags by hand.
- Merge your PRs to
main. Main squash-merges, so each PR title must be a valid Conventional Commit. - Open a
chore: release X.Y.ZPR that bumpsversioninpyproject.tomland__version__insrc/nomba/_version.py(a test checks they match), and renames## [Unreleased]inCHANGELOG.mdto## [X.Y.Z] - YYYY-MM-DD(Breaking, Security, Added, Fixed, Changed, in plain language). - Merge it.
publish.ymlbuilds it (lint, type-check, test, build,twine check, install-and-import smoke), then waits. Open the run in Actions and approve the pypi deployment. Only then does it publish to PyPI with Trusted Publishing and create thevX.Y.Ztag and GitHub Release.
Ordinary merges are no-ops: the workflow skips versions already on PyPI.
| Change since the last release | Bump |
|---|---|
feat!: or a BREAKING CHANGE: footer |
major |
feat: |
minor |
fix: / perf: |
patch |
only chore: docs: refactor: test: ci: |
no release |
Before 1.0.0, breaking changes bump the minor version.
Check the registry directly:
curl -s https://pypi.org/pypi/nomba/json | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["info"]["version"], d["info"]["requires_dist"])'Then confirm the tag and GitHub Release exist, and in a fresh virtualenv run pip install nomba && python -c "import nomba; print(nomba.__version__)".
- GitHub: create an environment named
pypiwith yourself as required reviewer, limited to protected branches, so a stolen login can't publish on its own. - PyPI: add a Trusted Publisher for the
nombaproject pointing at repoNombaOSS/nomba-python, workflowpublish.yml, environmentpypi. No PyPI token is stored anywhere. For the very first release, add it as a "pending publisher" (PyPI allows this before the project exists), so the first upload also goes through the workflow.