5 Commits

Include renames

Author	SHA1	Message	Date
logan	786d9c6110	fix(release): seed the version floor on the parent, not on HEAD ... The floor tag marks what has already been released, so tagging the commit being pushed leaves nothing between the floor and HEAD -- semantic-release then correctly reports there is nothing to release. That is what the first run did: it seeded v0.0.0 on the merge commit itself and cut no release. HEAD^ is the first parent, so on a merge commit it is main as it was before the merge and everything the merge brought in is releasable. The tag has been moved to 6fb7b5e by hand; this is so the next repo never needs that.	2026-08-17 20:37:43 -04:00
t	8d5d8af297	ci(release): keep the changelog out of a protected branch ... main is protected (enable_push: false, empty whitelist), so @semantic-release/git's commit-back is rejected by the pre-receive hook -- and it would be rejected *after* the tag was pushed, leaving a tagged release the run then reports as failed. Found by trying to push this branch to main. Whitelisting the CI user was the alternative and is declined: it weakens a protection someone set deliberately and lets a bot push to main without the checks every human PR has to pass. So the release page is the changelog. The changelog plugin now writes a gitignored .release-notes.md, which exists only to carry the notes into gitea-release.sh without interpolating them into a shell command, and CHANGELOG.md is a signpost -- a file claiming to be a changelog while silently never updating is worse than no file. Tags are not protected, so the tag push is unaffected.	2026-08-17 19:46:48 -04:00
logan	9ce79ee416	ci(release): release from a branch, not a detached HEAD ... semantic-release resolves the release branch and then pushes a commit and a tag to it, so a local branch named main is a better starting point than the --detach the other five workflows use. Still pinned to the pushed commit rather than to whatever main points at by the time the container starts. The floor tag falls back to the PAT when GITEA_TOKEN is unset, which is safe rather than merely convenient: all four publishers skip v0.0.0 explicitly, so the worst case is four jobs that start and immediately say there is nothing to build.	2026-08-17 19:21:19 -04:00
logan	b3a0814f24	docs: describe the release pipeline where the claims used to be wrong ... CLAUDE.md said .releaserc.yml was a config nothing ran and that there were five workflows; both stop being true with this branch. The CI section now names release.yml as the entry point and records the four things in it that are load-bearing, including the two silent failure modes worth pinning against. packaging/homebrew/README.md and docs/android-release.md say where a user would actually look that upgrading from 1.x needs a reinstall -- Homebrew offers nothing silently, and Android refuses outright.	2026-08-17 18:43:17 -04:00
logan	087eb77875	ci(release): cut a release from main with semantic-release ... The config has been sitting in .releaserc.yml complete and uninvoked; this is the workflow that runs it, and the one Gitea-shaped adaptation it needs. @semantic-release/github speaks GitHub's API, not Gitea's /api/v1, so @semantic-release/exec calls scripts/gitea-release.sh instead. That script reads the notes out of CHANGELOG.md rather than taking them as an argument: release notes are rendered commit messages, so interpolating the notes into a shell command would be an injection whose input is the commit log. The tag is pushed with a user PAT because Gitea does not start a workflow from a ref pushed by a workflow's own token, and the three publishing workflows are keyed on it.	2026-08-17 18:38:55 -04:00