Release Process

The release procedure lives in RELEASE.md in the repository root, next to the scripts it describes. This page is a pointer so the two cannot drift.

The short version

triepack-version.txt is the single source of truth for the version. Nothing else is edited by hand:

vi triepack-version.txt             # 1.3.1 -> 1.4.0
./scripts/sync_version.sh           # propagate to every manifest and binding
vi CHANGELOG.md                     # write the [1.4.0] section
./scripts/sync_changelog.sh         # regenerate the releases page

Land that through review, then release what the tree declares:

./scripts/make-release.sh --check   # build and test all ten targets
./scripts/make-release.sh           # PR, wait for CI, merge, tag

The tag is what publishes. It triggers publish.yml (GitHub Release and npm) and pypi.yml (PyPI), both of which call the same gate first, so nothing reaches a registry from a red build.

Files you should never edit by hand

File	Generated by
every package manifest’s version	`scripts/sync_version.sh`
each binding’s `VERSION` constant	`scripts/sync_version.sh`
`docs/_config.yml` version, README title	`scripts/sync_version.sh`
`triepack_version.h`	CMake, from `triepack-version.txt`
`docs/releases.md`	`scripts/sync_changelog.sh`, from `CHANGELOG.md`
`tests/conformance/` fixtures	`tools/gen_conformance_cases.py` and the `fixtures` target

CI runs --check on all of these, so editing one by hand turns the build red rather than shipping quietly.

Versioning

Semantic Versioning:

MAJOR — incompatible API changes
MINOR — new features, backward-compatible
PATCH — bug fixes, no API changes

The on-disk format version is separate from the library version and moves only when the bytes in a .trp file change. A reader accepts any minor version of the same major.

For the full procedure — branch model, what the release script checks, the npm and PyPI trusted-publisher settings, and the release checklist — see RELEASE.md.