hansdezwart/bgclock
1
0
Fork 0
Code Issues Actions Releases Activity

Correct the tagging rule: F-Droid pins hashes, not tag names

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
hansdezwart
2026-08-12 10:21:12 +02:00
co-authored by Claude Opus 5
parent 862b029953
commit b6d8f4e234
1 changed files with 22 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
RELEASING.md
+22 -4
View File
@@ -71,12 +71,30 @@ git push
git push origin v1.1 git push origin v1.1
``` ```
**The tag must keep the `v` prefix.** F-Droid's `checkupdates` takes the tag name Keep tags in the `v1.1` shape for consistency, but nothing depends on it:
verbatim as the commit to build, so `v1.1` here means `commit: v1.1` in their `UpdateCheckMode: Tags` with no pattern matches every tag whatever it's called,
metadata. A tag named `1.1` would break the automation. 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 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 ## 6. Wait