fix: skip update check on local builds

[alejodelosrios]

What?

checkForUpdatesCmd and checkForV1RCCmd now return early on a local development build — an unstamped binary running outside any package sandbox. Snap and Flatpak builds are explicitly left untouched.

Why?

version defaults to "dev" (main.go:67), and make build / go run . build without ldflags (Makefile:25-26), so a source build is unstamped. detectInstalledVersion() then reports something that is never the running binary:

• With a packaged Matcha present, it falls back to the system package manager and returns that package's version — so the TUI advertises an update for a binary the package manager does not own.
• With no packaged Matcha at all, it returns "dev", which never equals the latest release tag.

Either way the notice fires on every source build, e.g. Update available: 0.44.0 (installed: dev).

The docs already frame source builds as contributor territory: "Building from source is not recommended for most users… Only proceed if you… want to contribute to the project or need a custom build" (docs/docs/installation.md).

Why the guard needs two conditions, not one

Testing version == "dev" alone would regress released builds. snapcraft.yaml and com.floatpane.matcha.yaml both build without ldflags, so snap and flatpak binaries are also unstamped — and those are managed by the update path (trySnapRefresh, tryFlatpakUpdate). Their runtimes always inject SNAP and FLATPAK_ID, so the guard uses that to distinguish a packaged build from a local one.

Build	stamped	sandbox	update check
make build / go run .	no	no	skipped (this change)
goreleaser / nix / make install	yes	no	unchanged
snap	no	yes	unchanged
flatpak	no	yes	unchanged

This mirrors an existing pattern: view/html.go:76-78 already uses os.Getenv(...) != "" in production to detect the runtime environment.

Tests

Table-driven coverage of all seven cases, including unstamped snap build and unstamped flatpak build. Removing the sandbox condition fails exactly those two. make lint, make test and go test -race are clean.

Known limitation

A developer running go run . from the terminal of a packaged editor (VS Code snap, or VS Code / GNOME Builder on Flatpak) inherits the editor's SNAP / FLATPAK_ID and will still see the notice. This fails conservative — showing the notice, not hiding it.

Not included

snapcraft.yaml and the Flatpak manifest not stamping main.version is a real bug on its own (a released snap reports dev), but it is a separate logical change. Happy to open it as a follow-up.

[floatpanebot]

Hi @alejodelosrios! Please fix the following issues with your PR:

• Body: Missing the ## What? or ## Why? headings required by the PR template.

[floatpanebot]

Benchmark report — no significant change

Metrics worse: 0 · better: 0 (threshold: ±3%).

benchstat output

goos: linux
goarch: amd64
pkg: github.com/floatpane/matcha/backend
cpu: AMD EPYC 9V74 80-Core Processor                
                           │    old.txt    │              new.txt               │
                           │    sec/op     │    sec/op     vs base              │
ParseSearchQuery_Simple-4    2.317µ ± 309%   2.325µ ± 15%       ~ (p=0.853 n=6)
ParseSearchQuery_Complex-4   6.572µ ± 119%   7.201µ ± 67%       ~ (p=0.937 n=6)
TokenizeSearchQuery-4        4.186µ ±  51%   4.519µ ± 29%       ~ (p=0.699 n=6)
geomean                      3.995µ          4.229µ        +5.87%

                           │  old.txt   │              new.txt               │
                           │    B/op    │    B/op     vs base                │
ParseSearchQuery_Simple-4    26.00 ± 0%   26.00 ± 0%       ~ (p=1.000 n=6) ¹
ParseSearchQuery_Complex-4   762.0 ± 0%   762.0 ± 0%       ~ (p=1.000 n=6) ¹
TokenizeSearchQuery-4        176.0 ± 0%   176.0 ± 0%       ~ (p=1.000 n=6) ¹
geomean                      151.6        151.6       +0.00%
¹ all samples are equal

                           │  old.txt   │              new.txt               │
                           │ allocs/op  │ allocs/op   vs base                │
ParseSearchQuery_Simple-4    2.000 ± 0%   2.000 ± 0%       ~ (p=1.000 n=6) ¹
ParseSearchQuery_Complex-4   23.00 ± 0%   23.00 ± 0%       ~ (p=1.000 n=6) ¹
TokenizeSearchQuery-4        9.000 ± 0%   9.000 ± 0%       ~ (p=1.000 n=6) ¹
geomean                      7.453        7.453       +0.00%
¹ all samples are equal

pkg: github.com/floatpane/matcha/tui
                    │   old.txt    │              new.txt               │
                    │    sec/op    │    sec/op     vs base              │
LogPanelView-4        168.6µ ± 16%   162.1µ ± 20%       ~ (p=0.589 n=6)
SearchOverlayView-4   183.1µ ±  7%   178.1µ ±  7%       ~ (p=0.240 n=6)
InboxConstruction-4   995.8µ ± 24%   926.5µ ± 20%       ~ (p=0.310 n=6)
geomean               313.3µ         299.1µ        -4.54%

                    │    old.txt    │               new.txt               │
                    │     B/op      │     B/op       vs base              │
LogPanelView-4        44.67Ki ± 51%   44.67Ki ± 51%       ~ (p=1.000 n=6)
SearchOverlayView-4   56.14Ki ± 41%   56.14Ki ± 41%       ~ (p=0.567 n=6)
InboxConstruction-4   874.2Ki ±  0%   874.2Ki ±  0%       ~ (p=0.303 n=6)
geomean               129.9Ki         129.9Ki        +0.00%

                    │   old.txt   │              new.txt              │
                    │  allocs/op  │  allocs/op   vs base              │
LogPanelView-4         714.0 ± 0%    714.0 ± 0%       ~ (p=1.000 n=6)
SearchOverlayView-4    926.0 ± 0%    926.0 ± 0%       ~ (p=0.773 n=6)
InboxConstruction-4   3.477k ± 0%   3.477k ± 0%       ~ (p=1.000 n=6)
geomean               1.320k        1.320k       +0.00%

_{auto-generated by benchmarks.yml}

Formatting issues have been resolved. Thank you!

[alejodelosrios]

Verified the sandbox case manually, since it's the part worth being sure about.

Same binary, same network, seconds apart — the only difference is one environment
variable:

./bin/matcha                          # unstamped, no sandbox → no notice
SNAP=/snap/matcha/x1 ./bin/matcha     # unstamped, sandboxed  → notice is back

The screenshot below is the second command (my locale is es, so the string is
translated): Actualización disponible: 0.44.0 (instalada: dev) — i.e. the update
check runs normally as soon as the binary looks packaged. A snap or flatpak user
keeps getting release notifications exactly as before; only a local source build
goes quiet.

The two table cases unstamped snap build / unstamped flatpak build cover this in
CI, and dropping the sandbox condition from the guard fails exactly those two and
nothing else.