From a926e901960a39448fd618c8abaa5faac135a01a Mon Sep 17 00:00:00 2001 From: mixeme Date: Mon, 27 Jul 2026 22:29:42 +0300 Subject: [PATCH] docs: give "Cutting a release" its pre-tag checklist MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The section began at the tag, so everything that has to be true before the tag exists was either implied or nowhere: the version bump was named only as the thing the tag must match, and the changelog entry, the test run and the push were not mentioned at all. The push matters because the tag has to land on a commit the forge has. The screenshots are the reason for writing this down. README.md is packaged into all three release archives and is what the forge renders on the project page, and nothing fails when the shots are stale — the release just ships pictures of an older GUI. This project changes visible UI most releases, so the default assumption should be that they need retaking. Co-Authored-By: Claude Opus 5 --- docs/DEVELOPMENT.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/docs/DEVELOPMENT.md b/docs/DEVELOPMENT.md index e6ac54d..11c01bc 100644 --- a/docs/DEVELOPMENT.md +++ b/docs/DEVELOPMENT.md @@ -275,9 +275,21 @@ and `CHANGELOG.md`, matching the local `package-*` scripts. ### Cutting a release -Bump `src/app/version.go`, then create and publish a release with a matching `v` -tag on the forge (GitHub Releases / Codeberg releases). You can do that from the -web UI or the CLI, e.g.: +Before tagging: + +1. Bump `src/app/version.go`. The tag must match it exactly. +2. Add the version's [CHANGELOG.md](CHANGELOG.md) section. +3. Retake the README screenshots (`images/screenshot_jobs.PNG`, + `images/screenshot_settings.PNG`) if the GUI changed its appearance. This is + easy to forget because nothing fails without it: `README.md` is packaged + inside every release archive and is what the forge shows on the project page, + so a stale shot advertises an application that no longer exists. Take them + from a real build, not from a development run with test data. +4. Run `scripts/test.bat` (or `go vet ./... && go test -race ./...`) and push + `main`, so the tag lands on a commit the forge actually has. + +Then create and publish a release with a matching `v` tag on the forge (GitHub +Releases / Codeberg releases). You can do that from the web UI or the CLI, e.g.: ```bash git tag v0.11.5