Fix release notes and stop shipping stale installers #16
Assignees
dtourolle (Duncan Tourolle)
Clear assignees
dtourolle (Duncan Tourolle)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dtourolle/jellytau#16
Reference in New Issue
Block a user
Two defects found while preparing v0.9.2. Both had been shipping for months, and both were invisible because the failure mode looked like success.
1. Every release note was the same 1,050 bytes
All 35 releases from v0.0.1 to v0.9.1 published byte-identical generic install instructions, with a "What's New" section that read "See CHANGELOG.md" — a link that does not resolve from a release page. Nobody could learn what changed in any release this project has ever made.
The body now comes from the
## <version>section ofCHANGELOG.md, and a missing section fails the release — notes that say nothing are worse than a build that waits for two sentences.The 35 published release bodies have already been backfilled from the changelog via the
teaCLI, so the history reads properly now.This also corrects something I introduced two commits ago: that change generated the body from
bun run release:notes. CLAUDE.md is explicit that its output is "a reviewed draft, not a final changelog", and publishing it unreviewed proved the point immediately — thev0.9.1..HEADrange contains a repo-wide prettier sweep, so every file insrc/counted as changed, their TRACES resolved to nearly the whole requirement matrix, and the draft claimed the release had added the entire application. The script now skips cosmetic commits and reports how many, but stays a local drafting tool.2. Every release from v0.1.0 to v0.8.2 shipped every Windows installer ever built
src-tauri/target/*/release/bundle/is not versioned, cargo never cleans it, and the runner reuses the target directory — so the copy step'sbundle/**/*-setup.exeglob collected the lot.Eight months, unnoticed, because there was nothing to notice it by: the upload loop reported success, the files were genuine, and the release page looked busy rather than wrong. It stopped only because an unrelated cargo-cache change wiped the runner's
target/— so it was dormant, not fixed, and would have resumed on the next release.The fix
scripts/check-release-artifacts.shis the backstop for whatever reintroduces one by a route nobody predicted. It runs before the SBOM, the checksums and the upload — all of which describe the file set, so a stale artifact must be caught before it is hashed and published as part of the release.Verified against a reconstruction of the real v0.8.2 accumulation:
Still on the release pages
The stale
.exefiles themselves are still attached to v0.1.0–v0.8.2. The backfilled notes no longer advertise them, but they remain downloadable. Removing them is destructive and deliberately not done here — say the word and I'll delete them withtea.Verification
bun run check· 1085 frontend tests + coverage gate ·format:check·lint(0 errors) ·check:links· traceability 90% ≥ 89% · the guard verified on both a clean set and the real failure.DR-219, DR-220, UT-210.
The plugin versions could not be matched upward without this: both tauri-plugin-log 2.9.0 and tauri-plugin-updater 2.10.1 require tauri ^2.10, and the tree was on 2.9.5. So the framework moves with them -- tauri 2.9.5 -> 2.11.5, tauri-build 2.5.3 -> 2.6.3, wry 0.53.5 -> 0.55.1 -- and every plugin's Rust crate and npm package is now pinned to the same version on both sides. That upgrade broke Android outright, and the breakage is the interesting part. Seven call sites in this crate reach JNI through ndk_context::android_context(), which reads a process-global pair of pointers. Nothing here ever set that global. `tao` did -- the windowing layer under wry, three levels below anything this project names in Cargo.toml. tao 0.34.5 called initialize_android_context() while starting the activity and our code read what it left behind. tao 0.35.3 keeps the same two pointers in a private struct and no longer publishes them. The result, on every launch, was: PANIC at ndk-context/src/lib.rs:72: android context was not initialized 8: ndk_context::android_context 9: jellytau_lib::run::{{closure}} Not a crash in our code, and not a change to our code: an undocumented side effect of a transitive dependency disappeared. Relying on someone else to populate a global is a dependency that does not appear in Cargo.toml and gives no warning when it goes. src-tauri/src/android_context.rs now owns that invariant instead of assuming it. JNI_OnLoad captures the JavaVM as the shared library loads -- the earliest moment available, and nothing in tao, wry or tauri defines one to collide with. The Context is resolved lazily via ActivityThread.currentApplication() and pinned as a global reference for the process lifetime, since ndk_context stores a bare pointer and does not own it. It publishes the Application rather than the Activity: SecureStorage.initialize() immediately reduces its argument to applicationContext anyway, and an Application cannot outlive itself the way a retained Activity would. Restoring the global keeps all seven callers untouched. Threading a VM and Context handle through five credential call sites would have been a larger change with more risk, on the credential path. Failure now degrades instead of aborting: it is logged and credentials fall back to the encrypted-file path, which the app already supports. Verified on a device, R8-minified, not merely compiled: [INIT] Android JavaVM and Application published to ndk_context Android SecureStorage initialized successfully Android Keystore available via SecureStorage [INIT] Using system keyring for credential storage [CodecDetection] Detected 7 video codecs: av1,h263,h264,hevc,... -- the real keystore path, not the fallback, and the app stays up. None of this is reachable by CI: nothing there runs the app. Also fixed here, both found the same way: - `tauri android build --apk true` is now `--apk`. The CLI took a value until 2.10; from 2.11 the stray `true` is a positional and the build fails before starting. Three call sites in build-android.sh and one in build-release.yml -- the latter builds the signed APK, by far the most-downloaded artifact. - scripts/build-android.sh ran `npm install` on its clean-build path in a bun project, ignoring bun.lock and re-resolving the tree. That is exactly how the plugin crate/package versions drift apart again. scripts/check-tooling.sh now fails on any npm/yarn/pnpm invocation or foreign lockfile, and runs in CI. DR-222, DR-223.