• v0.2.2 c251e4ded4

    mikebrandon released this 2026-09-18 21:54:12 +00:00 | 0 commits to main since this release

    The first build whose update surface tells the truth. Everything below was found by pressing the
    buttons on a real install of 0.2.0, not by a test.

    Three ways the update button was broken

    It could not appear. The check that feeds the only update control in the app ran once, on
    mount, and never again — and App never unmounts. The console starts the uploader, the uploader
    looks for a release when it starts, and it finds one moments after the UI has already asked.
    Measured: the window rendered at 00:13:37, an update to 0.2.1 was staged and verified at
    00:13:51, and no update control existed until the app was restarted. The only way to see the
    button was to already have a staged update from an earlier session — which is what happens to
    somebody launching the app twice while testing, and to nobody else.

    Applying one required capture to be running. The supervisor is the only thing that can apply
    an update, and it did so only from inside a loop that exists while capture runs. With capture off,
    pressing the button wrote a request file and the screen said the update "will be applied by the
    service" when no service was there to read it. The obvious instruction — start capture first — is
    the part that was not acceptable: it asks somebody to begin recording themselves in order to
    install a fix.

    The button said "Download". There is no download step. By the time it appears the installer is
    already fetched and verified, so the press applies it — the one irreversible action in this
    product — and it declared that it did not stop capture and never mentioned that it cannot be
    undone.

    What changed

    The update surface polls instead of asking once. The console starts a supervisor for this alone
    (--apply-update, no roles started, same verification against the compiled-in key) when none is
    running, and takes the request back if it cannot. Platforms that cannot apply an update now handle
    the flag rather than falling through to the normal path and starting capture. The button says
    Install and restart and carries both warnings, pinned by a rendering test.

    Also: a stale collector now says it is from an earlier build instead of failing as an empty
    result, and bundle signs and verifies what it packages.

    Signed, and proven before publishing:

    bundle: signed, and accepted by the key this build trusts
      trusted comment: timestamp:1789768400	file:here capture_0.2.2_x64-setup.exe
    

    SHA-256 28022669cef9e7dc096493276e9f0e39c1c9b2a66c15b80de4dd63ba64c79f0e


    Where this came from. This repository is a distribution point, not the source. The tag above is
    where the release was filed; it is not the tree that produced the installer. These bytes were built
    from HERE/Capture at d92c850.

    Downloads