/download/<page>/latest hands out unreleased builds: resolve it from the page's version.json (the promoted version), not the newest release row (homepage Download button)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 1mo ago ·closed by Colby Knox

Colby, this one is for you, from John (2026-09-08): the homepage Download button hands new users unreleased builds, because of how /download/<owner>/<slug>/latest picks its target.

What happens today. adom.inc links to https://wiki.adom.inc/download/adom/hydrogen/latest (and .../hydrogen-macos/latest). That redirect resolves to the newest release row on the page. Right now that is 1.0.281, while the version Adom has actually released to the public is 1.0.201: the one the product's public manifest, adom/hydrogen/files/version.json, serves, and the one every existing install is offered. A UT Austin student installed Hydrogen from the homepage on Saturday and got 1.0.230, an internal build that had never been through the release gate. Because his updater then compares his version with the public manifest and sees 1.0.201 as older, he can never be updated until a promotion passes 1.0.230. He is stuck on an untested build with no way forward.

How releases work now, in one paragraph. Adom products publish every build to an early tier first (a private page whose readers are the tier, read by login; the Bridge SDK publish skill on adom/adom-bridge, section "Release tiers", is the public description). The product's public page keeps every installer as a release, unlisted, because the manifest that public installs follow must be able to point at them later. A human promotion is a manifest edit: version.json on the public page moves to the promoted version, with promoted_by, promoted_at and promotion_attestation recorded in it. So on any page that carries a version.json, the released version is whatever version.json says, never the top row of the Releases tab. The newest release row is, by design, usually an unreleased build.

Ask. Make /download/<owner>/<slug>/latest (and any "latest" affordance the page renders: a download button, an install hint, the hero CTA) resolve like this:

If the page has a version.json with a version, redirect to that version's asset for the requested platform (the manifest names the URL directly: windows.installer_url, macos.*). That is the released build.
Otherwise, keep today's behaviour: the newest release row.
Optional but valuable: /download/<owner>/<slug>/latest?tier=insiders, resolved only for a login that can read the product's early-tier manifest, so employees can still fetch the newest build from the same button.

On the Releases tab, a small marker on the released row ("released to public", from the same version.json) would stop a browsing person from taking the top row by hand, which is the other way this happens.

Pages affected today: adom/hydrogen (public manifest 1.0.201, latest row 1.0.281) and adom/adom-bridge (public manifest 2.1.29, latest row 2.1.72). The homepage links need no change once the redirect follows the manifest. The fleet dashboard (insiders only) shows the consequence live: one public-tier user on an insider build.

2 Replies

Colby Knox · 1mo ago

Done on prod (git-wiki 2e01ee2, rolled out 2026-09-08 ~14:55 UTC), exactly as asked:

/download/<owner>/<slug>/latest reads the page's version.json; when its version names a release on the page, the redirect goes to that version's asset for the requested platform/arch. ?format=json and /api/pages/<owner>/<slug>/releases/latest carry released_from: "version.json", released_version and promoted_by. A promotion is a push of version.json, and the resolver's cache is dropped on that push, so the homepage link moves the moment the manifest does.
A page without a manifest keeps today's behaviour (released_from: "newest").
?tier=insiders resolves the newest row, only for a caller who is an insider of the page (org member, author, or grantee); anyone else gets 403 INSIDERS_ONLY with a hint. Same on the JSON twin.

The overview download card and the Releases tab follow the same rule: the card and the callout pin the released version with a "released to public" badge, the callout says "newer builds below (up to vX) are not released", and the released row carries the badge in the list.

Verified on prod after the rollout: adom/hydrogen resolves to 1.0.201 (version.json) while the insiders tier hands a member 1.0.282, and adom/adom-bridge resolves to 2.1.29. adom.inc needs no change. The student on 1.0.230 stays stuck until a promotion passes it; that part is the fleet's to sort out.

John Lauer · 1mo ago

Verified from here after your rollout: https://wiki.adom.inc/download/adom/hydrogen/latest now redirects to 1.0.201 (the manifest's version) while the newest row is in the 1.0.28x range, and adom/adom-bridge/latest to 2.1.29. Thank you, that closes the homepage trap without touching adom.inc. The stranded student is ours: his install follows the public manifest, so the next Hydrogen promotion past 1.0.230 moves him, and the pre-production gate now sits in front of that promotion. Recorded on the insiders page under "Where the files actually live".