bug(update): pre-0.15.2 binaries cannot self-update across the asset rename - one-time manual reinstall required #164

New issue

Closed

opened 2026-07-16 17:42:15 +00:00 by hexajon · 1 comment

hexajon commented

2026-07-16 17:42:15 +00:00

(Migrated from codeberg.org)

Hit right after cutting v0.15.2:

madtea update
Error: no release asset madtea_0.15.2_linux_amd64.tar.gz for linux/amd64

What broke

v0.15.2 renamed release assets to version-free names (madtea_linux_amd64.tar.gz) for permanently stable latest-download URLs. Binaries older than 0.15.2 construct the legacy versioned filename when self-updating, do not find it on the new release, and fail with the error above. This was a known, accepted consequence of the rename - old updater code cannot be fixed retroactively - but it deserves its own record because every existing install hits it exactly once.

Uploading legacy-named duplicate assets would NOT rescue old binaries: their updater verifies the asset against the GPG-signed checksums.txt, which covers only the new names; making that work would mean amending and re-signing a published release's checksum manifest. Not worth it for a pre-launch install base.

Fix (per install, one time)

Reinstall via any current channel; from then on the built-in fallback handles both naming eras:

curl -fsSL https://codeberg.org/sixfold_space/madtea/releases/download/latest/madtea_linux_amd64.tar.gz | tar -xz
./madtea_linux_amd64/madtea install

Binaries 0.15.2+ look for the version-free name first and fall back to legacy names, so they update fine both across old releases and all future ones (covered by TestRunUpdateLegacyAssetNameFallback).

Remaining work (what keeps this open)

Append an "Upgrading from 0.15.1 or older" note with the one-liner to the v0.15.2 release notes.
Verify a 0.15.2 binary self-updates cleanly to the NEXT release (closes the loop on the fallback in the live flow).

Hit right after cutting v0.15.2: ``` madtea update Error: no release asset madtea_0.15.2_linux_amd64.tar.gz for linux/amd64 ``` ## What broke v0.15.2 renamed release assets to version-free names (`madtea_linux_amd64.tar.gz`) for permanently stable latest-download URLs. Binaries **older than 0.15.2** construct the legacy versioned filename when self-updating, do not find it on the new release, and fail with the error above. This was a known, accepted consequence of the rename - old updater code cannot be fixed retroactively - but it deserves its own record because every existing install hits it exactly once. Uploading legacy-named duplicate assets would NOT rescue old binaries: their updater verifies the asset against the GPG-signed `checksums.txt`, which covers only the new names; making that work would mean amending and re-signing a published release's checksum manifest. Not worth it for a pre-launch install base. ## Fix (per install, one time) Reinstall via any current channel; from then on the built-in fallback handles both naming eras: ``` curl -fsSL https://codeberg.org/sixfold_space/madtea/releases/download/latest/madtea_linux_amd64.tar.gz | tar -xz ./madtea_linux_amd64/madtea install ``` Binaries 0.15.2+ look for the version-free name first and fall back to legacy names, so they update fine both across old releases and all future ones (covered by TestRunUpdateLegacyAssetNameFallback). ## Remaining work (what keeps this open) - [x] Append an "Upgrading from 0.15.1 or older" note with the one-liner to the v0.15.2 release notes. - [ ] Verify a 0.15.2 binary self-updates cleanly to the NEXT release (closes the loop on the fallback in the live flow).

hexajon commented

2026-07-17 19:17:13 +00:00

(Migrated from codeberg.org)

Live check passed - the remaining task is done. In an isolated Debian container (never the host, per the self-replace-on-host rule), a genuine v0.15.2 release binary self-updated cleanly to v0.17.0:

$ madtea --version
madtea version 0.15.2 (0e7cb125...)
$ madtea update
Updated madtea: 0.15.2 -> v0.17.0
$ madtea --version
madtea version 0.17.0 (aebfa725...)

v0.15.2 is the first release with the version-free asset names (confirmed: its release assets are madtea_linux_amd64.tar.gz etc, no version in the name), and the update resolved the latest release's version-free madtea_linux_amd64.tar.gz, GPG/checksum-verified it, and atomically replaced the binary. The 0.15.2+ fallback works across the asset rename to the next release. Anonymous fetch (no credentials configured) succeeded, as expected for a public repo. Nothing left to do here.

Live check passed - the remaining task is done. In an isolated Debian container (never the host, per the self-replace-on-host rule), a genuine v0.15.2 release binary self-updated cleanly to v0.17.0: ``` $ madtea --version madtea version 0.15.2 (0e7cb125...) $ madtea update Updated madtea: 0.15.2 -> v0.17.0 $ madtea --version madtea version 0.17.0 (aebfa725...) ``` v0.15.2 is the first release with the version-free asset names (confirmed: its release assets are madtea_linux_amd64.tar.gz etc, no version in the name), and the update resolved the latest release's version-free `madtea_linux_amd64.tar.gz`, GPG/checksum-verified it, and atomically replaced the binary. The 0.15.2+ fallback works across the asset rename to the next release. Anonymous fetch (no credentials configured) succeeded, as expected for a public repo. Nothing left to do here.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#164

No description provided.

Rows
Columns