Releasing
The release flow assumes a protected main (required checks, no direct pushes), which is good practice anyway:
flowchart LR
A["make version<br>(on main)"] -- "branch ncmake/release/X.Y.Z<br>bump + lockfile sync + commit" --> B["make changelog<br>review, extend, commit"]
B --> C[push, PR, merge]
C --> D["git pull<br>make tag"]
D -- "signed tag vX.Y.Z" --> E[GitHub release<br>+ tarball asset]
E --> F["make publish<br>(App Store)"]
make version (run on main) prompts for the new version, validates it against the latest tag (sort -V, must be greater), branches off into ncmake/release/X.Y.Z (branches created by ncmake always carry the ncmake/ prefix, so they are immediately distinguishable from hand-made branches) and commits the bump there: appinfo/info.xml, plus composer.json/package.json when present, plus the re-synced lockfiles (synced inside the containers, so the bump commit is complete and CI-clean).
make changelog (on the release branch) generates the ## [X.Y.Z] section for the version in info.xml from the conventional commits since the last tag, and inserts it above the previous release, together with its [X.Y.Z]: link reference to the GitHub release tag (the repository URL is derived from the origin remote). Only user-visible changes make it in: feat becomes Added, fix becomes Fixed, perf becomes Changed; build, ci, test, chore, docs, refactor, style, merge commits and the daily Transifex bot commits are left out. The rest of the file is never touched, so the generated section can be freely edited and extended before committing, and hand-written history survives. It also prints the exact commit command: while the bump commit from make version is still unpushed, the changelog is folded into it via git commit --amend --no-edit (one commit per release); otherwise it suggests a separate build(release): update changelog for X.Y.Z commit. Rerunning is safe: an existing section is not duplicated, and when nothing user-visible happened since the last tag it says so (add a hand-written section then, for example for translation updates). It runs git-cliff via npx in the node container; an app-provided cliff.toml overrides the built-in configuration.
make tag (back on main, after the merge) refuses to re-tag, refuses when CHANGELOG.md has no ## [X.Y.Z] section, shows a fat reminder that a tag freezes the current commit, then creates and pushes the signed vX.Y.Z tag after your confirmation.
When you publish the GitHub release, the shipped release workflow builds and attaches the tarball asset for you ↗; make dist produces the same tarball locally if you ever want to attach one by hand. make sign (base64 signature) and make release (dist + sign) come from the App Store module.
