wharfy 0.14.0 — a static latest.json for update checks

Jul 7, 2026

What’s new

wharfy release now writes a static latest.json to the same GitHub Release, alongside the archives and install.sh:

{
  "version": "0.14.0",
  "notes_url": "https://github.com/…/releases/tag/v0.14.0",
  "assets": {
    "macos-arm64":   "https://github.com/…/wharfy_0.14.0_darwin_arm64.tar.gz",
    "linux-x64":     "https://github.com/…/wharfy_0.14.0_linux_amd64.tar.gz",
    "linux-x64-deb": "https://github.com/…/wharfy_0.14.0_linux_amd64.deb",
    "windows-x64":   "https://github.com/…/wharfy_0.14.0_windows_amd64.zip"
  }
}

Its stable URL always points at the newest release:

https://github.com/<owner>/<repo>/releases/latest/download/latest.json

Why a static file

Whether a user installed through brew, scoop, apt, or curl | sh, “is there a newer version?” is the same question — but each vehicle answers it differently, and Windows often has no package manager at all. A static file at one stable URL answers it the same way everywhere: fetch, compare version to your own, done. No API, no per-vehicle logic.

The keys carry OS/arch (and package kind), so a product that wants to point the user at the right download can read the URL straight from assets. GoReleaser’s .deb/.rpm share the archive’s os/arch, so wharfy splits them by extension — a .deb never overwrites the linux-x64 archive entry.

What wharfy does, and doesn’t

wharfy generates the file, publishes it on every release, and defines the contract (schemas/latest.json). It does not inject an update checker into your binary — that can’t be done for an arbitrary, language-agnostic program. Reading latest.json and prompting the user is the product’s own runtime code; recommended shape is default-on, timeout, silent-on-failure, cached, opt-out.

Getting it

brew upgrade wharfy / scoop update wharfy / go install github.com/ShiroDoromoto/wharfy/cmd/wharfy@latest. On Linux, from the apt / yum repo.