From b6d8f4e234e4ec5dd6b5b0358a5dd03168061deb Mon Sep 17 00:00:00 2001 From: Hans de Zwart Date: Wed, 12 Aug 2026 10:21:12 +0200 Subject: [PATCH] Correct the tagging rule: F-Droid pins hashes, not tag names The v prefix was never the constraint. checkupdates resolves whatever ref it finds to a commit hash before writing the build entry, and Tags mode with no pattern matches every tag regardless of name. The rule that does bite: a hand-written build entry must pin a full commit hash. The 1.0 submission used the tag and a reviewer sent it back. Worth writing down because fdroid lint only checks this under RepoManifest, so the pipeline passes with a tag sitting in commit:. Co-Authored-By: Claude Opus 5 --- RELEASING.md | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/RELEASING.md b/RELEASING.md index 4b4587d..be3fbef 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -71,12 +71,30 @@ git push git push origin v1.1 ``` -**The tag must keep the `v` prefix.** F-Droid's `checkupdates` takes the tag name -verbatim as the commit to build, so `v1.1` here means `commit: v1.1` in their -metadata. A tag named `1.1` would break the automation. +Keep tags in the `v1.1` shape for consistency, but nothing depends on it: +`UpdateCheckMode: Tags` with no pattern matches every tag whatever it's called, +and F-Droid's bot resolves whichever tag it finds to a commit hash before it +writes the build entry. Never move or delete a tag that has been pushed — F-Droid may already have built -it. If a release is wrong, bump the version and release again. +it. If a release is wrong, bump the version and release again. (The recipe pins +a hash, so a moved tag can't retroactively change a version they already built; +it would just leave your repo disagreeing with what's on people's phones.) + +**If you ever write a build entry by hand**, its `commit:` must be a full 40-char +commit hash — never a tag, never a branch. Tags are mutable, so a tag there means +the thing F-Droid builds and signs can change under them, and they reject it on +sight. This came up on the very first submission and is easy to get wrong, +because `fdroid lint` doesn't check it under `UpdateCheckMode: Tags` — the +pipeline goes green and a human catches it days later. Get the hash with: + +```bash +git rev-parse v1.1^{commit} # ^{commit}, or an annotated tag gives you the + # tag object's hash instead of the commit's +``` + +This doesn't come up in a normal release: the bot writes the entry, and the bot +writes hashes. ## 6. Wait