pkgver=2026.8.18 / pkgrel=2, _commit=e624e9f... — pinned in #166 on 2026-08-25.
Upstream has shipped three tags since then:
v2026.8.19 — Hermes Agent v0.20.5v2026.8.27 — Hermes Agent v0.20.6v2026.8.31 — Hermes Agent v0.21.0
The PKGBUILD's own header comment says the reasoning for provisioning a runtime under ~/.hermes instead of pairing with a CLI is that "the package stays on the newest tag." That's currently not true — it's three tags and ~2 weeks stale, which took all of a week after the package got merged.
This isn't just cosmetic. The same comment block explains that app shell and runtime have to be commit-matched or the readiness probe fails with a 401 — that's the documented reason HERMES_DESKTOP_IGNORE_EXISTING=1 exists at all. On this machine, app.asar's package.json reports "version": "0.17.0" (that's actually upstream's own semver drift, tracks back to the v2026.6.19 tag naming, unrelated to the calendar pkgver — worth noting so nobody chases the wrong number), while the self-provisioned ~/.hermes runtime bootstraps against current upstream and reports v0.21.0. Two different version axes, both stale relative to today, in different ways — which is a confusing thing to debug from the user side with no obvious signal that the package itself is behind.
Given the package drifted within about a week of being merged, a static pin is going to need either an update cadence someone owns, or some kind of bump automation (Renovate/a cron PR bot/whatever's already used elsewhere in this repo for tag-pinned packages) — happy to hear if there's already a pattern for that here I should follow instead of filing this per-drift.
Repro: pacman -Si hermes-desktop shows 2026.8.18-2; compare against https://github.com/NousResearch/hermes-agent/releases/latest.
Ref: #166
pkgver=2026.8.18/pkgrel=2,_commit=e624e9f...— pinned in #166 on 2026-08-25.Upstream has shipped three tags since then:
v2026.8.19— Hermes Agent v0.20.5v2026.8.27— Hermes Agent v0.20.6v2026.8.31— Hermes Agent v0.21.0The PKGBUILD's own header comment says the reasoning for provisioning a runtime under
~/.hermesinstead of pairing with a CLI is that "the package stays on the newest tag." That's currently not true — it's three tags and ~2 weeks stale, which took all of a week after the package got merged.This isn't just cosmetic. The same comment block explains that app shell and runtime have to be commit-matched or the readiness probe fails with a 401 — that's the documented reason
HERMES_DESKTOP_IGNORE_EXISTING=1exists at all. On this machine,app.asar'spackage.jsonreports"version": "0.17.0"(that's actually upstream's own semver drift, tracks back to thev2026.6.19tag naming, unrelated to the calendar pkgver — worth noting so nobody chases the wrong number), while the self-provisioned~/.hermesruntime bootstraps against current upstream and reportsv0.21.0. Two different version axes, both stale relative to today, in different ways — which is a confusing thing to debug from the user side with no obvious signal that the package itself is behind.Given the package drifted within about a week of being merged, a static pin is going to need either an update cadence someone owns, or some kind of bump automation (Renovate/a cron PR bot/whatever's already used elsewhere in this repo for tag-pinned packages) — happy to hear if there's already a pattern for that here I should follow instead of filing this per-drift.
Repro:
pacman -Si hermes-desktopshows2026.8.18-2; compare against https://github.com/NousResearch/hermes-agent/releases/latest.Ref: #166