Ir al contenido

Blog

Releasesv0.49.1

v0.49.1

Esta es la nota de release tal como fue publicada, no una reescritura de ella. Las notas de release se publican en el idioma en que fueron escritas.

Four fixes, all found by watching 0.49.0 publish and then using it.

An update left the old version behind, and the app believed it

Measured on a real machine right after a real in-place update:

chimera-desktop.exe   ->  0.49.0     the shell updated
/api/version          ->  0.48.0     the backend did not

The backend process was fresh — spawned by the new shell, same second. Nothing had survived. A file had: the frozen sidecar is a PyInstaller bundle whose names carry versions, NSIS overwrites what it is given and leaves the rest, so upgrading merged the two releases and _internal held both chimera_agent-0.48.0.dist-info and chimera_agent-0.49.0.dist-info. importlib.metadata answers with the first it finds.

So the app kept offering an update to the version it already was. The badge never went away and the next launch asked again.

The installer removes the bundle before writing the new one now — after killing the processes that hold it open, never before.

The pipeline could not have caught this, and that is the part worth keeping. There is already a step called "the frozen sidecar knows its own version". It ran, and it passed: CI builds into an empty tree where exactly one dist-info exists, and the defect needs a previous install to merge with. It also encoded "not zero" rather than "the right one" — it now compares against the release being built.

⚠️ This fix does not apply to installing this release. It repairs the installer 0.49.1 ships, not the one that installs it. Updating from 0.49.0 will leave a stale dist-info behind one last time, and the badge may lie again until 0.49.2. Deleting chimera_agent-0.49.0.dist-info under sidecar-dist\chimera-backend\_internal and restarting fixes it immediately; the next update cleans it either way.

For twenty-five minutes after every release, auto-update was broken for everyone

The updater asks for releases/latest/download/latest.json, and a release becomes latest the instant it is created — while four platforms are still building. Measured on v0.49.0: the endpoint returned 404 the whole time.

Nobody had noticed because the check swallows every error so it never nags. A window in which no update can be found looks exactly like a window in which there is no update.

Releases are held back with --latest=false and promoted once the manifest is attached. Until then the endpoint keeps resolving to the previous release, whose manifest names a real version. The failure mode improves too: a build that dies halfway leaves the previous release as latest, so a broken release is simply not offered.

The "new version available" panel asked a question it could not answer

Its heading read "A new version is available. Update?" over a panel whose only two buttons are View release and Dismiss. Inside the bundle there is no third option: the panel is in the webview, on the sidecar's http origin, with no IPC to the Rust updater.

It states rather than asks now, and names what does start one — the tray's Check for updates. That label lives in two tables in two languages, so a test compares them per language: pointing at a menu item spelled differently from the menu item is worse than pointing at nothing.

The first-run wizard was translated except for four words

Its cost-mode dropdown printed the raw values — auto / cheap / balanced / premium — in the middle of an otherwise fully translated screen. The labels already existed and were already translated; the Settings screen, which sets the same variable, had been using them all along. Two vocabularies for one setting is the app disagreeing with itself about what you chose.

Only the label. The value stays English, because the server takes a fixed set and would refuse a translated one.


Full notes: CHANGELOG.md

Leer la release en GitHub