4 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	e0427a3bb6	feat(ci/android): a release tag without Play notes fails before it builds ... Play does not show an empty "What's new" when the file is missing — it carries the PREVIOUS release's text onto the new version. So the store listing ends up describing a build nobody is getting, and nothing surfaces it except reading the listing. That is the shape of the v0.22.3 notes announcing a feature the tag never contained, and a soft warning in a log nobody reads does not prevent it. The gate runs FIRST in the job, before the ten-minute build: a miss costs a second and leaves nothing half-published — no build, no assets on the Gitea release, nothing on Play. It rejects three things: a missing file, a file byte-identical to another release's (the same bug reached by copy-paste rather than omission), and an empty or over-500-char one. Length is checked here as well as in play-upload.py on purpose. The uploader stays the last line of defence and is the only check android-promote.yml gets, but it runs at step 9; this catches an unedited TEMPLATE copy at step 1. It counts CHARACTERS, not bytes — Play's cap is 500 chars and `•` is three bytes in UTF-8, so a `wc -c` check would have called the 356-char v0.23.0 notes 365 and can reject a legal file. whatsnew/TEMPLATE.txt gives the file a starting point and says what the gate does and does not enforce: it cannot tell whether the prose was ever edited, so a copy that still reads "<The headline change>" ships exactly as written. Canary stays exempt — no curated notes, and Play reusing text for internal testers costs nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 10:34:32 +02:00
enricobuehlerandClaude Opus 5	09b9ee8f53	feat(ci/android): a release tag publishes to Play production, not alpha ... Production access came through on 2026-08-01. Until now a `vX.Y.Z` tag could only reach `alpha` and someone had to promote it by hand in the Console; it now goes to `production` at 100% (`completed`). Canary is unchanged on `internal`, and its run-number versionCodes always outrank production, so testers keep getting the newer build. A tag therefore reaches real users with no further click. What keeps that honest: the tag is only pushed once every platform is green, and Play reviews each production release before it ships. Ramping instead is `--status inProgress --user-fraction 0.2` on the upload step. Play's "What's new" gets its own file, docs/releases/whatsnew/vX.Y.Z.txt — the vX.Y.Z.md body is ~34 KB against a 500-char cap, so it cannot be reused. Only tags have one; canary is a moving target and Play carrying the previous text over is fine for internal testers. Same freeze rule as the notes: once the tag exists, the file describes what that versionCode shipped. android-promote.yml is the lever for everything that is not a fresh tag — promote a tested build, halt a rollout, or roll production back onto an older versionCode. It is separate from android.yml because promotion must not rebuild, and an `if:` on all ten build steps is worse than one small workflow. dry_run defaults to true, so a mis-typed versionCode validates and deletes the edit instead of publishing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 09:29:20 +02:00
enricobuehlerandClaude Opus 4.8	bda015b101	docs(release): rewrite v0.19.0 notes for end users + set end-user notes voice ... Release notes were written for the people who build Punktfunk, not the people who use it — dense with protocol/ABI/type names that confused even technical readers. Rewrite v0.19.0 in a benefit-first, plain-language voice (New/Improved/Fixed) with all internal terms removed from the body and every protocol/ABI/embedder detail moved to a single bottom "Under the hood" section. docs/releases/README.md now codifies this voice as the format spec for all future notes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 20:15:08 +02:00
enricobuehlerandClaude Opus 4.8	15d09a8c10	feat(ci/release): author release notes in-repo + announce stable releases to Discord ... Release notes now live in the repo at docs/releases/vX.Y.Z.md, authored during the version bump (before the tag). ensure_release (gitea-release.sh + .ps1 twin) seeds the Gitea release body from that file in the create POST, so the release is born WITH its notes instead of being created empty and PATCHed afterward. canary/rc have no file -> empty body, unchanged. New manual `announce` workflow (workflow_dispatch, tag input) re-syncs the notes file over the live release and posts a violet embed (title, notes lead-in, release-page link) to the Discord #releases channel via the DISCORD_RELEASE_WEBHOOK secret. Stable-only: a -rc tag is refused unless allow_prerelease=true. Pressing "go" is the quality gate, so a half-built or failed release is never announced. docs/releases/README.md documents the ritual; TEMPLATE.md is the skeleton. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 16:43:18 +02:00